Well, my understanding is (but I have yet to personally experience) the migration from 17 -> 18+ is rough because of all the javax.* packages being renamed jakarta.*

Which likely means touching a pretty significant portion of your codebase for the upgrade, and then who knows what 3rd party libraries you depend on are expecting...

So it may be as simple as Find/Replace for some folks, for others, it might be a deep dark rabbit hole.

Not breaking things used to be Java's MO. Yes, that means a ton of legacy cruft built up over the years... but we used to be able to depend on Java to "Just Work".

Perhaps some of this is necessary. After all, the C# folks seem to have no problem breaking everything to add new features... but I'd assert the Java community as a whole is much less tolerant of breaking changes and rapid deployment of features.

There are entire segments of the industry that has never touched any javax package - while no doubt widespread, I do believe that it is still a very fair price to pay, and none of these changes were even half as problematic as for example the python 2->3 migration. So I don’t know, I’m fairly sure it is impossible to keep a platform alive with even less/smaller impact breaking changes.

javax -> jakarta is entirely dependent on your dependencies not the vm.

There’s plenty of dependencies that provide javax implementations as well as jakarta.

8 -> 9 wasn’t that hard for me personally. For our applications it was just adding things to the build to make sure javax.xml was present.

The real difficulty for us was upgrading the Play framework since the Scala community likes to make breaking changes with every release.