But, Java 8 will stop receiving public updates next year, and pretty much everywhere I've looked, folks are sticking on Java 8.
I am hoping I'm wrong, but I wonder if we will see Java 8 be forked, and live on, by community effort, as the cost to maintain it would be lower than the cost of risking moving to Java 11. For a lot of businesses, I don't think the reality has set in yet, and I don't think they're going to realize what situation they're in until Java 8 hits EOL.
Granted this is an extreme case but large, complex critical systems need a certain amount of stability and upgrades across Java releases are not quite as easy as just touching the servers.
Would you agree that the breakage between 1.4 and 1.5, 1.5 and 1.6, 1.6 and 1.7, 1.7 and 1.8 is not comparable to the breakage that Jigsaw alone introduced between 1.8 and 1.9?
However stuff like JDBC interface changes comes up as breaking changes in previous releases.
In what concerns Java 9, Mark Reinhold keeps doing presentations about how all Java relevant frameworks and tools are already Java 9 compliant. Including many that they validated against in Maven repositories.
Last presentation I saw was at FOSDEM.
So it appears to be a major issue to anyone wanting to migrate Java 9 without updating the frameworks as well, having some kind of special case library, or using APIs that were always documented as internal.
The QA outreach page [0] suggests maybe about half the projects are ready. The ones that aren't include Netty and SLF4J. Those aren't small projects. Is that page outdated or does "JDK9 ready" not really mean "JDK9 ready"?
EDIT: Maybe it's outdated; SLF4J and Netty do claim to be JDK9-ready.
Honestly I never needed any java updates on server side. I'm sure that they are fixing something important, but I've yet to encounter any bugs. My recent projects should run on Win32 and given that they dropped support, I won't migrate from Java 8 even if it won't be updated.
Can you provide examples of those vulnerabilities? All vulnerabilities I'm aware of are from Java applet technology and not applicable to server applications. The only vulnerability that I can remember is something about parsing float, but even that was very low risk.
I don't use TLS and even if I would use it, I would use nginx frontend. My subset is fairy common, Spring+JDBC, sometimes Hibernate, sometimes pure servlets, but basically all interaction between outer world is via HTTP interface implemented in Tomcat.
A targeted attack would probably hole you fairly easily then. Cleartext means you’re likely open to all sorts of replay attacks and data leaks, which can then be escalated to exploit vulnerable libs and jvm.
But, Java 8 will stop receiving public updates next year, and pretty much everywhere I've looked, folks are sticking on Java 8.
I am hoping I'm wrong, but I wonder if we will see Java 8 be forked, and live on, by community effort, as the cost to maintain it would be lower than the cost of risking moving to Java 11. For a lot of businesses, I don't think the reality has set in yet, and I don't think they're going to realize what situation they're in until Java 8 hits EOL.