I'm coming in as someone who helped get thousands of Java 8 based SpringBoot 2.x apps to Java 17/21 and SpringBoot 3.x, so a non-trivial portion of my last year

I'm coming in as someone who helped get thousands of Java 8 based SpringBoot 2.x apps to Java 17/21 and SpringBoot 3.x, so a non-trivial portion of my last year. The javax -> jakarta namespace was a part of the issue. Turns out, we had a lot of things using jaxb as either a direct or transient dependency. About 10% of the apps were some form of old school Java EE which faced the same issue. None of the porting is hard once you've sat down and done it once - but we had team after team who were doing it the first time. We also got to find out who was using deprecated packages, as release by release from 9+, they started to be deleted. Way too many libs were using Sun's base64 encoder. The point here is that Java is getting updated and the core JDK is just fine. We are seeing components drop support for Java 1-8, requiring 9+. And yes, that could happen in any ecosystem. It is happening in Java ecosystem today. If you crawl GitHub and look at what is vibrant and what is becoming abandoned, you will see the unmaintained legacy stuff stuck on Java 8. CVEs are a terrible way to say security risk - but it does show trends. Since about 80% of our Java apps are SpringBoot based, when SpringBoot 2.7.18 being the last 2.x community release that reached EOL in November of last year. That version released with Spring Framework 5.3.31 - Spring Framework is currently 5.3.41 or so for those getting commercial patching. This is the last version that supported Java 8 through 11. Similar issue with MapR. This traps people on specific Java versions, which then traps them to an aging ecosystem of components. The parent asked - why not target Java 8? That is why. If the parent asked, should I be compatible with Java 21-8, I'd say fine. It is a company's fault if they found themselves on an EOL product. Please, for the love of god... don't enable teams to remain there by making ANYTHING that requires Java 8. None of this is hard until you have so many that it is.