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

[bug77]

I'm not the world and lots of government stuff here are all SOAP. Can I use jlink with an EAR? don't think that's going to work on jboss

Nice try, but on JBoss/WildFly, you just include jakartaee-api-<version>.jar and the implementation of your choice, you don't need JAXB support in the JDK.

[mcloud]

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.

I'm not the world and lots of government stuff here are all SOAP. Can I use jlink with an EAR? don't think that's going to work on jboss

[darkonix]

Do benchmarks against. Oracle java, you will fund out that OpenJDK is trash

Why don't you share your benchmark so we can see that?

[ruthan]

Do benchmarks against. Oracle java, you will fund out that OpenJDK is trash

[Michael_S]

As far as migrating Java versions forward, at a previous job we had many thousands of tests that depended on a floating point rounding bug in Java 7. Of course we didn't know about the bug dependency until we tried to upgrade to 8 and got a wall of red in local builds and continuous integration tests. That took a few months of tedious work to fix.

I think a bigger problem is that a lot of aspect-oriented-programming/bytecode-enhancement libraries have specific dependencies to JDK versions. So you try to upgrade library Foo, and you discover it depends on Bar, and Bar depends on Baz, and Baz does bytecode manipulation and is locked to JDK version X or older. So you upgrade Foo to get a newer version of Baz, and it turns out that the new version of Foo has API changes. You and your teammates all know that eventually moving to a newer JDK version will pay for itself in the dual wins of improved runtime efficiency and more readable and maintainable code. And the sooner you can get to Lambdas/Streams/Records/better case statements/green threads/etc... the less code you'll need to rewrite later.

But selling your manager and the product team on the investment to upgrade Foo so you can upgrade your JDK? Good luck with that. They're not paid to care about an impossible to hard-quantify productivity boost in six months that will give even greater but still impossible to quantify boosts next year. Their performance is measured based on delivering features to customers this quarter.

[caligula]

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.

Python 2 -> 3 transition has been really slow. For many projects it tooks years to do it. There was a tool for performing some of the changes automatically, but it was still quite complex. Java has always had excellent compatibility. Even now people are complaining because they don't understand the concept of modules and don't see how they can compile or run their old code with later Java versions. It's usually quite simple. Sometimes you need to switch to a new library or to a fork that has different package names, but the same classes. Those are simply needed because in the modular world, two modules can't contain any of the same packages.

[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.

[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.

[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

[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.