pour one out for the legend
The way releases used to work for the past ten years or so was that after a major release, every couple of months there would be a bugfix/security patch, and every six months (for a year or more) there would be a feature release (that used to be called "limited update") with major new features (new GCs, new monitoring mechanisms etc.) but without spec changes to the language and libraries. This meant that all the changes that required changing the spec had to wait for the major release. This had several bad implications. Most if not all of the spec changes were no more disruptive than the changes in the feature releases, but they had to wait for the next major release -- a lot of changes delivered at once created an overall fairly large disruption. Also the major release had to wait for the large features, and people couldn't enjoy smaller ones. Finally, people wanted to get their changes into the next major release so they wouldn't have to wait another three years or more, so features were merged before they were fully tested, which meant that the .0 major release was noticeably less stable.
So, to make the upgrade process easier and cheaper, Java got rid of the major releases, allowed making spec changes in the feature releases, and, with the major releases gone, every feature release gets a new integer name. The result is a much more gradual process. Every feature release is about as big and only slightly more disruptive than the old feature releases. The releases are now much more stable because features are merged only when they're mature enough; there's no rush because if you miss a release, there's another in six months.
The ecosystem will take some years to adjust, but those who've made the transition to running in production on the current release (many still can't, as some tools haven't yet adjusted) report a smooth process.
Upgrading a code base because of language evolution is pure cost for most people. It's a relatively risky and almost zero-reward exercise for mature applications.
You've got 3rd party library/dependency drag, tooling drag (everything from IDEs to CI/CD pipelines), development effort for code changes or QA and testing resources. Your engineers have to invest time in learning about the language and library changes. Never mind that unless you do a total rewrite, you end up with an incoherent code base which mixes old and new styles.
All this busy work/effort could instead be applied to adding features, eliminating bugs, improving performance, etc. - changes that end-users actually appreciate or that add business value.
Java conquered the enterprise precisely because it was slow moving and stable and offered unparalleled backward compatibility. Pretty much, the very same reasons Microsoft windows conquered the business world. This is (was) Java's strength not the weakness you portray.
Let's face it, at this stage Java is never going to be "cool" again the way it was in the 90s. Trying to join the "move fast and break things" school of language evolution just makes it look like a middle aged person (I'm one btw) trying to be "hip" by emulating young teenagers in dress and speech. At the same time you're alienating your existing users.
After that there was no effort to upgrade to all subsequent versions, to this point.
At least our shop made it to JDK 11. Next LTS version is 17, which is a while out.
https://developer.android.com/studio/preview/features?hl=ru#...
We’re bundling an OpenJDK 11 with our product and while I’ll definitely play around with v14, I think we’ll only upgrade once v17 LTS is out.
