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
Post a Comment