>Java 8 had its end-of-life for commercial usage in january 2019

_Oracle's_ Java 8 end-of-lifed, but many other vendors provide TLS for their respective Java implementations.

Just a correction: they are not separate implementations. Almost all vendors use Oracle's Java implementation -- OpenJDK. It's just that only Oracle and companies that license the source from Oracle (like Azul) can release non-GPL builds based on OpenJDK, so other vendors maintain old OpenJDK versions by doing their own backporting from the mainline, where most of the work is done by Oracle.

Amazon Corretto and Azul are making decent efforts for this. You can also find openjdk 7 versions with some support still.

For actively developed projects, I would recommend moving to java 11 without too much delay unless you have pressing technical or business reasons not to. If it's dead code and it is not causing issues, don't mess with it too much.

The Java 8 to Java 11 upgrade is unfortunately somewhat disruptive due to the module stuff. That affects some projects that depend on JVM internals, which tends to include e.g. older versions of application servers. Upgrading those is a bigger deal usually.

Some companies spend longer than six months to discuss/agree to a 'major version upgrade' of software.

Naturally the gap between (say) Java 10 and 11 is fairly small, meaning it shouldn't take many months to merely discuss an upgrade - but not all companies have got round to the regular-release way of thinking.

Java 8 was released March 18, 2014, so they had 5 years to upgrade.

But I see your point about the new release schedule, where the LTS version is not supported after 6 months.

I think the companies need to change their mindsets. New Java version are backwards compatible, as they introduce changes gradually.

It is actually more dangerous to wait, because they risk that some features (like GC) are deprecated after 4-5 versions. By updating regularly and keeping an eye on deprecated features, they should have time to adjust

I still need to pass weird flags for Tomcat to make it work under Java 9+, almost 6 years later. Modules were a mistake. If not for modules, a lot of people would have migrated to 9+.

Modules were certainly the biggest upgrade barrier ever in the history of java. But the have enabled a way for the JDK to get smaller without them we would face the JDK getting bigger with each release, which is not sustainable.

So on reflection I think it was a good move. Most frameworks and libraries work on modules now.

Modules where not a mistake but we will likely benefit from it in say at least 5 years. Every artifact/library you use has to be a (real) module to be able to use it's full potential.

I've yet to see a real world use that is meaningful. Mostly it just adds deployment bureaucracy for opting in to stuff that used to be there by default. I'm not seeing a huge adoption of modules outside of Java's core libraries.

A good thing that came out of it was that it forced them to untangle the 2 decades old standard library. This was disruptive but it seems to have also unblocked a bit of progress and also allows the to have experimental modules in non lts releases (9,10,12,13).

The LTS versions are supported past 6 months. Java 11 has 2 years of public updates through AdoptOpenJDK. The next LTS (17) will no doubt have similar.

It doesn't matter so much, as Java is backwards-compatible to stone age. If the company has finally settled on a backlog, they can start with whatever LTS version is the most recent one.

It's only a drawback for hired hands that may have become used to the features in v13 and then land a gig where they have to scale back to v1.6, that has to hurt.

I thought the whole point of backward compatible versions, is that you don't discuss, you just move.

It's not really an "update every 6 months" thing - I imagine most companies will stick to the LTS releases which are less frequent.

Not really. The real world seems to move much slower. I'm not sure if Android even fully supports 8 yet.