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

[Termy]

Please stop this "mutually-incompatible versions" nonsense.

Tell that to people playing different Minecraft Versions

I'm surely no java expert, but i can't remember any other language that caused so many version-related headaches in my life...

[Sonadow]

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.

Back in 2012 we had a customer using an ancient enterprise program that absolutely requires Java 1.6 and only Java 1.6. Its bundled startup script is also written to specially look for Java 1.6, otherwise the program will simply refuse to start.

One day I got adventurous and modified the script to point it to Java 7. It threw exceptions all over the place almost immediately. On both XP, Vista and Windows 7. So it had absolutely nothing to do ancient OS libraries and everything to do with Java incompatibilities.

Fast forward to 2023 and that program now lives in a Hyper-V VM with a 32-bit Vista guest. And still with Java 1.6. And the customer still uses it to this day.

[bug77]

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.

Yes, they did. Because they used internal classes that they weren't supposed to and the developers didn't really care.

For those that don't know, Java has an official API. That's documented here: https://docs.oracle.com/en/java/javase/21/docs/api/ and meant to be used for building applications. Besides that, there is another set of APIs, that are not included in that page and are not meant to be used by anyone not implementing a JVM. Those classes were always marked as unstable and subject for potential removal. But some would just use them anyway. Whether because they were easier to access than adding a proper dependency to your project (e.g. there wasn't a Base64 encoder in Java for a long time, but there was an internal class that would provide Base64 encoding and people flocked to that instead of adding a dependency like bouncycastle). And there was other set of APIs in the unsafe package. People didn't shy away from using those either, to gain a quick and dirty performance boost. Iirc Scala itself had trouble getting v3 out of the door because of heavy reliance on unsafe API calls.
What Java lacked, was the means to actually make those APIs inaccessible to those that were not meant to access them. This got added in the meantime, was left in there for a few versions, spawning warning for everyone to update their code and then the mechanism was actually enforced.
That was a one-off and it was announced years in advance.

[skeevy420]

Tell that to people playing different Minecraft Versions

I'm surely no java expert, but i can't remember any other language that caused so many version-related headaches in my life...

As an end-user, Python.

And it really isn't Python itself, it's Pip and all the dependencies pulled in by Python projects. Sometimes dependencies are in repositories, sometimes they're not. Sometimes what's in the repository matches upstream, sometimes they don't. All that can be really annoying when it doesn't Just Work.

[bug77]

Back in 2012 we had a customer using an ancient enterprise program that absolutely requires Java 1.6 and only Java 1.6. Its bundled startup script is also written to specially look for Java 1.6, otherwise the program will simply refuse to start.

One day I got adventurous and modified the script to point it to Java 7. It threw exceptions all over the place almost immediately. On both XP, Vista and Windows 7. So it had absolutely nothing to do ancient OS libraries and everything to do with Java incompatibilities.

Fast forward to 2023 and that program now lives in a Hyper-V VM with a 32-bit Vista guest. And still with Java 1.6. And the customer still uses it to this day.

I don't know how you concluded it was about Java incompatibilities since, by your own admission, that thing was hardcoded for Java 6. And you're not telling me what kind of errors you saw either (understandably, I'd be surprised if you remembered after all these years). Some errors can have nothing to do with the language at all, they can be caused by the updated CAs that come bundled with the JDK/JRE or by the removal of some encryption/decryption algorithms that have been proven vulnerable in the meantime.

Fwiw, my experience is usually the opposite: I'm begging management to allow a JDK/JRE upgrade and they refuse because they're afraid "code will break", no matter how many (hundreds or thousands of) automated tests I have in place saying otherwise.

The current problem with the Java ecosystem, imho, is that we now have jlink and even native-image (sort of) that will completely side-step any incompatibilities issues. Yet hardly anyone has bothered to make proper use of either. jlink is hard to use because you can still run into libraries that are not properly modularized and it will have a hard time telling what it needs to include and what not. native-image is in a perpetual state of "almost production ready, but not really" and it only exists for GraalVM, which isn't the default JDK for many projects (i.e. not even available unless you take some extra steps).

And don't get me wrong, after using Java in prod for 2 decades now, I have my fair share of complaints about it. But compatibility doesn't rank high on that list.

[deck]

Back in 2012 we had a customer using an ancient enterprise program that absolutely requires Java 1.6 and only Java 1.6. Its bundled startup script is also written to specially look for Java 1.6, otherwise the program will simply refuse to start.

One day I got adventurous and modified the script to point it to Java 7. It threw exceptions all over the place almost immediately. On both XP, Vista and Windows 7. So it had absolutely nothing to do ancient OS libraries and everything to do with Java incompatibilities.

Fast forward to 2023 and that program now lives in a Hyper-V VM with a 32-bit Vista guest. And still with Java 1.6. And the customer still uses it to this day.

So this organization failed to do basic software maintenance on this application and this is somehow a JDK problem? I am curious, have you ever tried a similar upgrade with C or Python?

My experience has been the opposite, following the JDK upgrade path hit some challenges when upgrading to JDK 9 and JDK 17, but every other version upgrade has been completely painless. Conversely, upgrades with major versions of Python (especially Python2 to Python3) was really painful. For me, the Python upgrades hit compatibility issues both within Python space and within OS space, and trying to run Python2 and Python3 at the same time was a complete disaster.

I think lots of apps stay on old versions of the JDK because the OS compatibility between versions of Java is very good. It's trivial to run two versions of the JDK on the same VM or OS. Doing the same with C or Python, or other languages with similar 20+ year lineage is far more difficult.

[luizluca]

Java 21 introduces the notion of sequenced collections

It is a shame that the Smalltalk team that built Java didn't influence java collections enough since the beginning. The collections in Smalltalk are still ahead of most, if not all, current languages.

Java also still lags behind on expressivity. That's also another Smalltalk characteristic that could make java a much nicer language. What you could write in a couple of lines in Smalltalk will take pages with Java.

[andrei_me]

Have you tried to read the manual and find the command line args to very likely make your ancient unsupported apps run on a modern JVM? .

Exactly, my old jars ran fine with Java 19, just had to change my bash command and add the needed

--add-export=java.desktop/sun.awt.image=ALL-UNNAMED​

or something like that and done

[caligula]

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

I suppose you don't have any idea what kind of initialization is involved in a C program before main() can be executed. Assuming e.g. dynamically linked, x86-64 PIE executables built to run on Linux.

[caligula]

It is a shame that the Smalltalk team that built Java didn't influence java collections enough since the beginning. The collections in Smalltalk are still ahead of most, if not all, current languages.

Java also still lags behind on expressivity. That's also another Smalltalk characteristic that could make java a much nicer language. What you could write in a couple of lines in Smalltalk will take pages with Java.

Java could have collections similar to Kotlin or Scala, but Java's libraries assume mutable data structures. A combination of immutable structures and declaration site variance annotations would simplify some cases. Modern Java has pretty decent syntax for collection "literals". There are also new "shortcuts" for transforming from one form to another. This sequenced collections feature actually just unifies some things at the level of interfaces and documentation, but it was partially available already before. Some of the canonical properties of collection elements could have been more modular, but I guess that was hard to achieve in the early days. There are few problems with the signatures on the API level. I don't agree with all the design decisions involving universal equivalence and polymorphism.