Java 21 / JDK 21 Reaches GA With Virtual Threads, Generational ZGC

[browseria]

My exact thoughts before coming into this thread.
Every time I hear about a JVM update I'm always excited to hear what new tech goes into it - and then become disappointed when I realize that nobody is going to use it.

I just spent the afternoon converting our entire code base (about 2 million lines of code in 9 different microservices and a javascript frontend) from Java 17 to Java 21. We will go to production with this as soon as the automated integration tests complete (they are about 75% done right now). Anyone that is still running on Java 8, I encourage you to simply run your Java 8 app on a Java 21 VM - especially if it is a memory intensive app. The improvements in G1GC alone should be incentive for you to finally drop Java 8 and get current. Unless you like wasting money running the garbage collector, that is.

[mcloud]

Please stop this "mutually-incompatible versions" nonsense. There was exactly one major "removal" of APIs from Java and it was related to internal classes that were never meant to be used outside of the JDK (they always came with a disclaimer): https://openjdk.org/jeps/403
Everything else was a few method calls here and there, related to ancient stuff: https://docs.oracle.com/en/java/java...oved-apis.html

Whatever programs are still stuck on Java8 are stuck because they depend on ancient libraries that aren't updated (probably full of CVEs by now) or because their developers don't care anymore.
Irl I have only found one instance where it was hard to move off Java 8 and that was because it ran on embedded (I know, I know) and further JDKs regressed in performance too much. Not because anything was incompatible.

Not only that, sure, these are real problems, but not only them. In my case, I got bitten by the removal of the jaxb and jaxws apis and the only way I can run a program on a newer JVM is to bundle them with my app. But that makes it totally incompatible with the existing jdk8 install and I have no automated way to upgrade everything on all installs

[archkde]

Haven't run into that one yet. But if you happen across something that was spun off into a separate module... just pull the module?

Yes, but the problem was (note the past tense, also in my original post) that some build tools simply didn't know how to "just pull the module".

[Saljack]

Not only that, sure, these are real problems, but not only them. In my case, I got bitten by the removal of the jaxb and jaxws apis and the only way I can run a program on a newer JVM is to bundle them with my app. But that makes it totally incompatible with the existing jdk8 install and I have no automated way to upgrade everything on all installs

It is a really huge problem to add two libraries on your class path. You can bundle them with your JDK. I would like to know what will you do when you realize that the most new versions of libraries use jakarta namespace instead of javax?

[NotMine999]

It only took them 28 years to notice Java's fundamental flaw.

Seems just as complicated as C++ yet it makes C look rather simple ... almost BASIC.

[grung]

To all people complaining about Java apps not being upgraded - keep in mind that you can run almost any version of java on modern os. If you have to use jre8 today - you can. Not everything have to be upgraded and let's be honest it won't be if it works and maintainer don't have time to do that.

And what is best in most cases you can download jdk as a User and just run it - no root needed. This alone makes it perfect for enterprise environments. That's why java IDEs are (or were) so popular.

Try that with python or rust or go.

Regarding java8 to 9 switch - yes it was painful but had to be done and I think it was done well.
Same problem was with decommission of JavaEE and moving to Jakarta. At the end of the day it waa done and world moved forward.

Python 2 to Python3 upgrade was much worse.

Next big thing for java will be GraalVM, they do amazing job maintaining the compatibility and one day I bet apps will work seamlessly as java program and AOT binary.

Saying all this above - java is designed for business applications, service oriented most of the time and not for small programs. There are better languages to write simple terminal programs in most of the cases

[bug77]

Not only that, sure, these are real problems, but not only them. In my case, I got bitten by the removal of the jaxb and jaxws apis and the only way I can run a program on a newer JVM is to bundle them with my app. But that makes it totally incompatible with the existing jdk8 install and I have no automated way to upgrade everything on all installs

Well, the world kinda removed SOAP, too, so removing it from core Java was definitely the right thing to do.
If you worry about deployment, you have jlink.

[bug77]

Yes, but the problem was (note the past tense, also in my original post) that some build tools simply didn't know how to "just pull the module".

The module system spent the better part of a decade in the making, if the tools weren't able to deal with that, that's hardly a Java issue. But yes, the issue would have affected Java as a whole.

[archkde]

The module system spent the better part of a decade in the making, if the tools weren't able to deal with that, that's hardly a Java issue. But yes, the issue would have affected Java as a whole.

I didn't say it's a fault of Java as a language (which it certainly isn't, since it's in fact completely unrelated to the language at all), but it was an issue that at the time prevented a huge bunch of Java applications from migrating to newer versions.

[saboya]

Not sure what world some people live in, but there were plenty of big libraries that took a LONG time to be Java17-compatible (example: Flink https://issues.apache.org/jira/browse/FLINK-15736), so yes, compatibility IS a big issue in Java world.