Eclipse OpenJ9 v0.42 Released With OpenJDK 21 Java Support

[Mangogeddon]

About the "other benefits":
#1 is called Class Data Sharing (https://docs.oracle.com/javase/8/doc...a-sharing.html) and is not particular to OpenJ9. It's just not in widespread use so not many people know about it. Again, mostly superseded by native-image and AOT compilation.
#2 is also not particular to OpenJ9 (https://ieeexplore.ieee.org/document/5679914), though I can't recall where else I have this implemented.

#1 I looked into the current implementation of CDS, and the OpenJ9 version seems more comprehensive in terms of feature set. Also, AOT/native-image may require application changes, whereas CDS/SCC do not. Native-image compilation is also not currently fully reproducible, that was an issue for us when we were looking at it.
#2 you're probably thinking of the commercial Azul JVM. They have a similar LLVM-based feature, though it's not available in their open source JVM offering.

[bobbie424242]

OpenJ9 has its place in the Java landscape.
It uses a lot less memory by default (at the expense of potentially being a bit slower than Hotspot, which for a whole class of Java software does not matter much), thus a good option for memory constrained devices and containers.
And has others pointed, it can be an alternative to GraalVM's native-image with the Class Loading stuff described in previous posts.
OpenJ9 is also a good match to run with IBM's OpenLiberty web framework. It is also tailored to run on IBM's mainframes.

[bug77]

#1 I looked into the current implementation of CDS, and the OpenJ9 version seems more comprehensive in terms of feature set. Also, AOT/native-image may require application changes, whereas CDS/SCC do not. Native-image compilation is also not currently fully reproducible, that was an issue for us when we were looking at it.

Fair enough.
Though I would add what worries me more about native-image is not reproducibility (if you validate an executable and push it, you can use that indefinitely), but that you need another layer of tests. Regular developer integration tests* usually manipulate/mock at least some dependencies, thus they do not test the final, native code. I, for one, still haven't figured out how to integrate such tests in the build pipeline.

#2 you're probably thinking of the commercial Azul JVM. They have a similar LLVM-based feature, though it's not available in their open source JVM offering.

Could be, my memory fails me on this one.

*Because "integration tests" means a million things to a million people, I would want to clarify my definition is "tests that address the integration of the components in a given project, while mocking out external systems". Or, if you wish, the maximum you can test without having to fire up other systems (e.g. database, a distributed cache, an authentication server).