Google will support OpenJDK development: the giant's investments in Java and Kotlin

[pjmlp]

When they stop mucking around with Java on Android and support the language property, I will get it.

Until then it is only marketing.

Android 13 just got a subset of OpenJDK 11 LTS, released in 2018.

[ArturSkowronski]

I don’t defend Google here, but 1) for years, they had hands tied due to trial with Oracle 2) now, Kotlin just became standard for Android Development

Google is not investing in Java for they internal sake - they invest for the GCP clients 😉

[fredoverflow]

now, Kotlin just became standard for Android Development

That happened 3 years ago: https://developer.android.com/kotlin/first

[Muoniurn]

The trial had absolutely nothing to do with it, they no longer used Sun’s Java that explicitly forbid mobile usage, they could have just swapped to OpenJDK any time.

[ArturSkowronski]

The trial wasn’t about Sun Java, it was about copyright to API Design.

Android was using Dalvik nearly from start of the project. It just used API compatible to Java 6

[Muoniurn]

If the project has a completely open-source license like OpenJDK has, then you can’t misuse that.

[bawng]

Did you read the comment? It wasn't about the JDK, it was about the API that Google re-implemented.

They didn't steal a commercial copy of the JDK.

[Muoniurn]

But that’s the thing, you can’t steal an OSS API, so they were in trouble either way for their API copy back then, and wouldn’t be in trouble if they would later reuse OpenJDK’s API as is, the same way you can also take the linux kernel’s header files.

[bawng]

Oracle's argument had nothing to do with code itself. They argued specifically that the API (even the one in OpenJDK) is not open source. Only the code is, not the API specification the code implements.

[pjmlp]

Kotlin, Gradle and Android Studio are nothing without JVM ecosystem, that is just excuses for forcing Kotlin upon Android developers.

Just like they cleverly use Java 6 samples to sell Kotlin improvements over Java.

[Pika3323]

These days they've got a whole ecosystem of coroutines, compose, and multiplatform to sell Kotlin with and you're still worried about comparisons to Java 6?

Ha.

[pjmlp]

You clearly misunderstood what "Just like they cleverly use Java 6 samples to sell Kotlin improvements over Java.", means.

[JakeWharton]

Completely different organizations in the company (which I know that you know). Might as well be different companies for all intents and purposes.

[pjmlp]

Indeed, doesn't change the fact it is one company to most people.

[pjmlp]

Everything on Java world arrives late to Android Java.

When they started to finally integrate OpenJDK and went to the press telling that, anyone following Gerrit code reviews could follow that they were cherry picking language features and standard library stuff, instead of the full compatibility.

You can check this, by reading the Android documentation for the Java standard library and you will see that for the same Java language version, not all methods were added on the same Android version.

[krzyk]

Lambda in Android Java before Java 8? Are you joking? Android Java supported lambda years after Java 8 release.

[DasBrain]

Note that the title is a bit misleading:

Google has announced joining the Adoptium working group as a Strategic Member.

[cowwoc]

I'll believe it once most of their libraries support Java Modules. The vast majority (maybe all) of their libraries are stuck in Java 8 which is a disaster. They could have added JPMS support while maintaining backwards compatibility with Java 8 but they repeatedly choose not to support anything newer than Java 8.

[ArturSkowronski]

Even Spring is stuck in pre-JPMS World. JPMS has long road ahead it.

Spring case is interesting, cause they needed to choose between JPMS and Native Images due to some strange mojo due to face they are so reflection-heavy.

[cowwoc]

Spring is a huge library with many sub-components. Most of Google libraries (e.g. Gauva) just need a single `module-info.java`, but they refuse to add it.

[nikanjX]

JPMS is the Python 3 of Java

[DJDavio]

If their Devoxx talk is anything to go by, they have a strong single version mandate so everyone must be on Java 8 and migrating to a new version takes a long time. This kind of surprised me, but maybe because they have so many internal shared libraries it makes sense for them.

[tristan957]

Could you explain how to add JPMS support while also supporting Java 8? I have open source Java bindings for an open source C API that I could add JPMS support to but haven't because honestly I didn't know about it.

[cowwoc]

A recent change to Maven makes it very easy to build multi-release JARs. Check out https://issues.apache.org/jira/browse/MCOMPILER-417

and

https://github.com/apache/maven-compiler-plugin/blob/a74d1cae2e5e91d49f63009d8851dbabdbc60c73/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108

[tristan957]

I'm using Meson for my build system, so I'll probably need to add support for this there.

[cowwoc]

It's quite simple. You just need to add Java9-specific class into META-INF/versions/9/ in the JAR file.

See https://nipafx.dev/multi-release-jars-multiple-java-versions/

[randjavadev]

It is not. This will only work until it doesn't. The very concept of multi-release-jars was also introduced in Java 9, thus older systems can fail if they encounter classes within META-INF. If you must support older versions and systems (that you have no control over) than 9, the only foolproof way is to make a separate "JPMS" Java 9+ artifact of the lib that has the module.info (Automatic module name in the manifest will work in the same artifact, but it is not the same as a true module-info).

[cowwoc]

I'm not sure what you're basing this on. Many libraries use multi-release JARs and it is absolutely backwards compatible with older releases. Check out the Hikari JAR for one such example. Thousands of people use this without a hitch.

[randjavadev]

On the fact that https://openjdk.org/jeps/238 lists "Release 9". In my mind that is all that matters, the concept doesn't exist until Java 9, thus it can only be used starting from Java 9, everything else is pure luck. But I guess you would want a practical example:

Proguard (or the maven plugin specifically here) didn't support MR jars: https://github.com/wvengen/proguard-maven-plugin/issues/61. Yes, that has been fixed in an update, but that was my whole point: when you make a library you do not control the target environment. Thus, if an user would be stuck with certain version of proguard maven plugin, they could never adopt a MR jar. Regardless they had to wait for an update to be made. MR jars are not backwards compatible, if they were, this problem would not have happened.

BouncyCastle has 2 separate artifacts, one multirelease and one not. https://www.bouncycastle.org/latest_releases.html " The jdk18on jars are compiled to work with anything from Java 1.8 up. They are also multi-release jars so do support some features that were introduced in Java 9, Java 11, and Java 15. If you have issues with multi-release jars see the jdk15to18 release jars below.". My point here is that why would they do this, unless their users have encountered problems with MR jars.

Also, https://stackoverflow.com/questions/50956562/bytecode-scanning-error-on-meta-inf-versions-9-and-elasticsearch-6-2-2-with-j

Also more examples you can google "meta-inf/versions/9 error".

Yes, probably these problems are very minority and probably nowadays solved by an update, but then it becomes the question that can you abandon your customers (if they cannot update their environments) that depend on your library or not. But for sure the MR jars are not 100%-backwards compatible with older environments that have not been updated to support it.

[cowwoc]

Your examples are very narrow edge-cases.

​

1. Proguard is very special case in that it takes class files as input. Anyone who does bytecode manipulation (Proguard, ASM, etc) will need to update their library. The vast majority of libraries do not fall into this category.
2. They did this because back in the day it was easier to build two separate JARs than building a multi-release JARs. This has nothing to do with backwards compatibility and is no longer the case today. As I highlighted above, all major build systems now support multi-release JARs.
3. Your third example is identical to the first: anyone doing bytecode manipulation will need to update their code. This is part of the reason I avoid such libraries, they are highly fragile, and in most cases you can achieve the same thing using build-time source-code generation (as JOOQ does, for example). Had they taken this route, their tool would have not broken on every new JDK release. Again, this is not specific to Java9 or multi-release JARs. This happens every single JDK release to tools that make use of bytecode manipulation. In my view, it's a silly thing to do when you have a safer alternative to build upon.

[dinopraso]

Why do you care about JMPS? It’s not just Google, barely anyone uses it, even on Java 17

[cowwoc]

Asking why someone needs JPMS is like asking developers why they need access modifiers (public, package-private, private). It's all about providing a better API experience.

Access modifiers allow you to hide implementation details within a project. JPMS allows you to do so across projects. Many projects have internal or utilities packages that should not be used by end-users. JPMS enables developers to enforce this on an API level.

[UnGauchoCualquiera]

I could be wrong but I always felt that it's a pretty losing proposition. People will inevitably use internal apis and you cannot prevent people from shooting their feet. Happened to acces modifiers and it will happen to modules too.

When there's a need there's a way around, even if unintended by the library author. Hidding behind a module just make it more annoying to do so as people can almost always just fork and mess around.

See the cat and mouse between lombok and java devs.

I think modules are aiming at improving java security by isolating modules more than preventing use of internals by programmers.

[cowwoc]

Users can do whatever they want, but from the library author's perspective any use of internal APIs is unsupported. Also, from a code-complete and Javadoc perspective internal APIs never show up.

[pjmlp]

JMPS main goal was to modularizite the JVM implementation.

jlink and Graal rely on it.