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

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

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

[ruthan]

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

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

[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

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