I disagree. That has not been my experience whatsoever. Every company I helped, and it's been dozens, had struggles moving to a new versions of the JVM. Every single time there were major issues that required a lot of re-work and re-testing. I bailed around Java 17 or 18, but it didn't matter because NOBODY I was working with was actually even using that version! On one particularly bad project in 2022, a client had a security imperative to update the JVM from 1.5 on a major internal system and my role was to determine efficacy. I quickly found out that several key libraries had ceased support long ago around Java 1.7 and there was no path forward for those. They were simply deprecated products. My team tried getting the source code and re-compiling those 3rd party jars, with the idea of taking ownership of that code, but it was spiraling in terms of scope. They would not listen to me that even getting them to 1.7 was going to be problematic. Worse, some drive-by manager would not believe my appraisal and brought another guy to prove me wrong. It turned into this big pissing contest, which I resented. The other resource wasn't anywhere near as experienced as me, just kind of arrogant and overly confident. I decided to fire that client, which sucked because they were the tippy top of the Fortune 10. Last I heard, they had not made any progress with that upgrade and were still using it on 1.5.

Yes been there but technically this has nothing to do with Java but mis-management. The same issue could have occured in a company with Typescript or C++ for that matter. Keeping your software secure requires maintanance and requires active monitoring of 3rd party libraries and occational switching of libraries and partial rewrites. Sticking you head in the sand and hoping to keep everything running without maintenance will at some point require a full rewrite or extreme high costs to get to a product without CVE's.

This must be satire