[sh87]

I totally agree with this. I have worked in stable, long term, revenue generating projects that relied on java and its slow stable releases. I now cherish that we could focus on features and not have a "Migrate to Java x.x" story looming upon us.

With NodeJs, its a semi-annual affair to move and migrate or face unexpected broken 'npm install' commands. Fix the tooling, fix CI/CD, ignore warnings, application upgrades now require installing newer Node versions, no backward compatibility guarantees of any kind. Its a fool's errand.

I hate to see Java go this route. I don't think this will end well for the Java ecosystem.

[pron]

Java has had the six-monthly feature releases (which were called "limited update" releases, as opposed to major and patch releases) for many years, with names like 7u4 or 8u20. They also had a support period of 6 months. For example, the 8u20 feature release got two patches, names 8u25 and 8u31, and then 8u40 came out and 8u20 no longer got patches. But people are confused by the choice to give those releases a new integer name now that major releases are gone.

It is an extreme misunderstanding to think that Java does not have "backward compatibility guarantees of any kind." Backward compatibility is of the utmost importance (Java has never made breaking changes as big as Python or .NET have), but it is not absolute. It's never been absolute; it's just that while breaking changes were mostly accidental before (or to implementation details), Java now admits some changes to the spec. But note that those aren't the changes that people have noticed (the biggest ones were removing methods that no one used). The breaking changes that people notice are implementation changes that some libraries, due to technical debt, relied on. As more investment is being put into the JDK and it's changing more quickly, that technical debt is showing, but it's not because of breaking spec changes.