not op, but in my company: all the people who wrote the systems left decades ago for better paying gigs. Broken CI/CD culture, DevOperations people are afraid to write (or unwilling to learn) IaC for deployments, must manage things by GUI (made at the time when JDK 1.8 was released). Developers are not engaged nor motivated to learn new tooling/best practices nor interested in migrating off JDK 8, since it just 'works' so why change it. Mgmt does not know much about tech so does not know that 'severe' technical rot is happening

I think for most people it's the introduction of the module system. If it causes code to break in libraries you're using and there's no direct replacement for those libraries, it's a big hill to get over.

I think it's a mix of complacency, the change to a LTS model, internal governance, and lack of awareness. The company will only get off their ass once 1.8 no longer receives any updates. Looking at some of the older tickets in the system, this was the case when java 7 was no longer supported (massive influx of migration tickets in '15).

A Spring Boot project with a good number of dependencies, the bleeding edge Spring Boot supports newer Java, but then you need to worry about Hibernate's compatibility with the latest Spring Boot, etc.

I think at least some of my dependencies still rely on reflection features that are limited by Java 9.

Not OP by the way

In my case: infrastructure group declines to support different Java versions for different use cases. We have a lot of Spark 2.x code, like thousands of different jobs. Spark 2.x only supports Java 8.

Java 8 Code is Code that works in Android. Android Java severely broke compatibility after Java 8.

If you want to write shared Java libs that work on both client/server, you need to stick to Java 8.