Time to make an exception to the LTS version policy?

Virtual Threads Improved 

I'm starting to dip my thoughts back into technology, in preparation for getting back into interviewing and getting back to working.

This week I had a listen to the latest episode of Josh Long's "A bootiful podcast" and was surprised to hear a strong push for going with non long term support (LTS) versions of Java.

A few days later I was watching a presentation about how NetFlix is using Java in 2025 (JavaOne presentation on Youtube), sure enough there Java 24 is also being applied in order to benefit from improvements to the use of virtual threads.

JEP 491 "Synchronize Virtual Threads without Pinning" seems to be enough of a driver for some organisations to push forward outside of the Long Term Support versions.

Non LTS in prod?

I've seen companies apply a simple policy of only permitting LTS versions in production, so now I'm curious about whether the broader Java community is moving away from that approach.

Potential Migration Limitation

For the types of systems that I have worked on in the past, I can see a potential blocker to slipping out of the LTS versions - cloud providers such as AWS offering systems such as AWS lambda are still only supplying LTS versions of the Java runtime in their bundled Java offering. 

So if you have workloads running in Docker or directly on an EC2 instance you wouldn't be able to smoothly transition it across to AWS lambda.

Just a matter of time

Java 25 is scheduled to be the next LTS version, so if you are prepared to wait a few months then sticking with the "LTS only" policy could also work okay.

Comments

Popular posts from this blog

Speeding up Software Builds for Continuous Integration

2022 - A year in review

Running Java with Preview Features in the Cloud - Part One