I don't know what you mean - if that's the case why didn't they realise that in like 2015, 2016, when these Java 9 features were added? And why haven't they been able to fix them since then?
I know about development realities, but seriously come on at some point?
8 -> 9+ is an entirely different story, because not only was 9 the last (ever) major release, but it was a particularly big one.
> If your code ran on a given Java 7 release, it would work unchanged on all later Java 7 releases; the same for Java 8. The same pattern still applies for later Java versions; if your code ran on a given Java 9 release, it should work unchanged on all later Java 9 releases, but not necessarily on Java 10 or Java 11 (this is not a theoretical concern, I've seen it happen in practice).
But the situation now is even better. If your code works on 9, it will work with no or very few changes on 10 and if it works on 14 it will work with no or very few changes on 15, but while there might be slightly more work between 14 and 15 than between 8u20 and 8u40, in exchange you never have another major upgrade again. So the work is just spread differently, and in a way that makes it less costly overall, true, once you've got used to it.
But there's one more difference to those who do remember how things were: It is true that in the Java 6-7 era there weren't as many breaking changes, but that was mostly because Sun was dying and Java barely changing. With Oracle's growing investment, change is picking up, and the new release model makes it easier to cope with, not harder, as those who'll skip too many feature releases are sure to find out.
> You not only have to upgrade your code (and hope your QA and unit tests caught all relevant cases) for the new Java version, but you also have to upgrade all your dependencies,
I'd say that such a policy is based on folklore and/or luck rather than actual long-term experience. You have to do that for every patch release, too (although "upgrading your code" is not something that's very common in Java; most JDK 1.4 code still runs unchanged, and the required changes are mostly on the command line, not in the code). It is not the small spec changes that are most likely to break your code in complex ways, but internal changes that occur even in patches. The change that required the most code changes since 9 has been this one [1], in 11.0.2/8u202 -- i.e. a patch release, not a feature release.
The one area where there is more need to update dependencies on feature releases than patch releases is in bytecode parsing/manipulating libraries, some of which for some historical reason (a bad ASM accident about 8 years ago) still insist on shadowing ASM into their JARs. As a consumer of such libraries, you should advise them to stop.
> It could reasonably be years before many shops transition to Java 9
Java 9 is short term support release, ending support with the release of Java 10 / Java 18.3 (March 2018). Next LTS JVM release is supposed to be 11 in 1.5 - 2 down the road.
A lof to large organizations will be holding back for the next LTS release before considering migration.
reply