I agree, Java compatibility is much better now. For Java 9 there were also runtime breaking changes like removal of javax classes and removal of javaFX.
>6 months is not really a long time for enterprise software.
But Java has always had semi-annual feature releases, and there wasn't even LTS -- people had to upgrade to a new feature release ever six months. It's just that we dropped major releases altogether and then gave the feature releases new version numbers, and that confused many people (who might not have even been aware that some of the minor releases in the past were actually quite significant feature releases). In other words, people upgraded to new feature releases every six months in the Java 7 and 8 era, too; now with major releases gone it's even easier, so it doesn't make sense that projects that were fine with such upgrades in the past all of a sudden need the new LTS model when things are even easier than before.
Would those intermediate releases make breaking runtime changes like dropping nashorn, removing APIs and changing default encoding modes?
That’d be pretty bad behavior when maintaining backward compatibility.
I know of a very large education company that trained their support staff to downgrade the Java 8 version of end users when they experienced problems (until they dropped Java on the front-end for web). Maybe the feature releases is why?
They're not "intermediate releases". In the past there were three kinds of releases, major (every few years), feature (aka "limited update", every six months), and patch (every quarter). Now there are two: feature and patch, with the feature releases getting the integer numbers now that major releases are gone. Oracle's sales arbitrarily selects some feature versions for which to offer an LTS service, and other companies follow their choice. BTW, they can choose to offer LTS even for releases that have already been made and retroactively make them "LTS releases." There's absolutely nothing special about them, and the development of the JDK ignores the availability of such offerings. We produce feature releases, and if someone wants to pick some of them to offer support services for longer durations than for other versions -- that's up to them.
Feature releases, now and before, sometimes made what you call "breaking runtime changes" that might require changing the command line. Actual breaking changes to APIs are rare, now as before (e.g. the last major release, 9, removed sound 6 methods, I think, and that was probably the biggest such change in Java's history, although the future degradation of the Security Manager is probably bigger). One difference between feature releases now and then is that, with major releases gone, feature releases can change the spec. This virtually always means adding new APIs.
> Maybe the feature releases is why?
Feature releases existed in Java 8, too, people just forget because they didn't get their own version number back when major releases existed. They were even less reliable back then. The biggest factor in Java compatibility issues is without a doubt libraries relying on JDK internals. That was less of a problem in the 6-7 era for the simple reason that Java stagnated due to lack of resources in Sun's last years. JDK 16 finally turned on strong encapsulation, so this problem is likely to recede.
I'm not saying that upgrading feature releases is risk-free, but it's always been that way, only people forgot or didn't notice so much with the old numbering scheme, and LTS wasn't available then at all. And it's also likely that the upgrades now are slightly more difficult, but in exchange there is no need for major upgrades ever again. For actively developed code, upgrading with every feature release is overall easier, cheaper and safer than staying on an old version, skipping updates, and doing a big transition every few years.
When the version number scheme changed and LTS was introduced, many companies got confused and stopped their practice of upgrading to new feature releases. At the same time, many don't understand what LTS is or that the free offerings don't actually maintain the full JDK, just backport fixes from mainline to the intersection of the existing features (e.g. Nashorn and CMS aren't getting maintained in the free "LTS" offerings).
>6 months is not really a long time for enterprise software.