So I have been in Java versioning hell before, and I empathize--but that was, like, Java 5 to 6. My experiences with Java since then have been almost completely seamless. So, this may be a silly question, but I'd be curious: what is so disruptive to your workflow that upgrading a JDK, running your test suite under instrumentation to smoke out incompatibilities and noticeable perf/memory/etc. regressions, and deploying it would cause you to not "get anything else accomplished"?
I can't speak for the OP, but from what I've seen in other organizations a reluctance to upgrade JDK versions usually indicates a lack of confidence in their test automation suite. If they can't be confident that their tests will catch regression defects then a JDK upgrade seems risky and requires planning ahead for a major manual testing effort. This is just one area where getting to 100% automated functional testing delivers huge benefits.
Pretty much right on the nose. As I mentioned elsewhere, testing is not required where I work. As such, there's no guarantee that upgrades to JDK won't break something behind the scenes now only to blow up later in production.
Most test suites cannot test long-term stability. We once had a commercial J2EE app that would run fine for weeks on JDK 7.x but commit continual-GC suicide or burn 100% of all cores after about 24 hours on JDK 7.x+1.
After this happened with multiple oracle “bug fix” releases, we of course stopped upgrading as much as possible, spending days trying to determine if each security hole being patched in the JDK was actually an attack vector for this app.
We also implemented periodic “therapeutic restarts” on all app servers.
It was like running a critical server app on Windows 95.
Major java versions have been known to have different default settings/properties from previous versions, without any mention whatsoever in the release notes.
Any 'minor' change in a user application, font being a common example, can have a significant negative impact for an enterprise that has built workflows around that application.
That assumes we have (any) tests, or benchmarks to refer to. Plus, we have a decent amount of legacy java apps (java 6 - 7) and we'd be going straight to 11. On the project I'm on now, it's not a smooth transition.
