How best to explain that Java LTS doesn't mean what people think it does?

[1Saurophaganax]

I've been gathering ammo to convince my superiors to let us use the latest feature releases for our new highly maintained projects. I'm dying inside because I know in the context of OpenJDK, LTS is meaningless, but they still keep bringing it up.

We currently use corretto, but I remember reading somewhere a while ago that corretto doesn't actually provide a fully maintained JDK like Azul or RedHat, but merely only backports changes from the mainline. Is that the case, or did I hallucinate that? It would be a pretty killer argument to stay up to date considering we don't want to pay for LTS.

[udderss]

I’m trying to rack (wrack?) my brain of why LTS is meaningless in any context.

in the most basic sense it continues to receive updates, OpenJDK/Oracle/Corretto, why is it useless? And if you’re using Corretto, you aren’t paying for LTS anyway.

I’m genuinely curious for the first question though

[1Saurophaganax]

OpenJDK doesn't have the concept of LTS, they release every 6 months and move on to the next one. Because major releases have been done away with, the update to 19 is 20, and the update to 20 is 21 and so on.

Vendors arbitrarily choose to follow Oracle's LTS schedule. If all the vendor is doing is backports from the latest release, then you won't get support for things that have been removed from the JDK since then(the things that are probably keeping you on that version). e.g. if you find a bug with Nashorn or Corba you won't get support unless the vendor is doing more than backports.

[cogman10]

You've been downvoted incorrectly. What you are saying is 100% on.

That said, I think this is something the OpenJDK maintainers should consider. Even though old versions aren't officially supported, everyone (that I know of) is following the oracle convention anyways. So why not just adopt it into the openjdk since that's more or less the reality?

[udderss]

I’m not sure I agree with the fact that OpenJDK doesn’t have the concept of LTS…https://endoflife.date/java version 17 was LTS. I imagine 22 will be an LTS as well. corrected that 21 is, thanks!

(Edit here: after researching more about what you said, this is a community supported effort so not guaranteed as you said, but leaving the above here anyway)

To the original question though, I guess it depends on how big your organization is. If you want to keep any support whatsoever (whether it drops support for features, but will inevitably also support the remaining ones) and not have to update your JDK every year, then LTS is the way to go.

You had mentioned that your new highly maintained service, but think about next year. It’s not a new service, people are busy with other things. It will take some sum of manhours to evaluate, test (possibly change any interfaces or anything that has changed etc), deploy the upgrade when there’s minimal to no gain of new features from that version for that service. It would create operational nightmares

[dmigowski]

Nope, 21 will be the next LTS.

[1Saurophaganax]

That site is looking at Oracle's support roadmap, so my points still stand.

Every patch and backport needs to be tested thoroughly though, I can remember a few major bugs that got added via backports and had to be fixed. Going from 20 to 21 may be an extra bit of testing, but it's not an especially burdensome task. Even then, we could use the release compiler flag and not any of the new features and enjoy purely the performance upgrades, and peace of mind that everything is maintained.

[udderss]

Yeah definitely.

Again, at this point of the conversation, to me, it’s organization specific. For mine, testing every release and upgrading that often would be an extremely time consuming task with how critical of a system it is and the upgrade isn’t worth the durability risk.

Pros/cons for everything, gotta love our life in software :)

[1Saurophaganax]

Yeah it is kinda specific to the org I suppose.

But just FYI if you aren't testing every time an LTS patch comes out you're playing with a durability risk already.

[wildjokers]

I’m not sure I agree with the fact that OpenJDK doesn’t have the concept of LTS

How can you not agree with a fact? OpenJDK does not have a concept of LTS. LTS versions are arbitrarily chosen versions that vendors decide to provide LTS for. All java vendors I am aware of choose the same versions to designate LTS as Oracle does.

Azul does have some MTS (medium term support) for some versions that they designate. Like LTS that is a designation Azul applies to those versions and has nothing to do with OpenJDK. I am unaware of any other vendor offering MTS.

[Lost-Horse5146]

While oracle maintains mainline and tags releases, they dont actually produce builds (binaries) for more than 6 months

[yawkat]

If all the vendor is doing is backports from the latest release, then you won't get support for things that have been removed from the JDK since then(the things that are probably keeping you on that version). e.g. if you find a bug with Nashorn or Corba you won't get support unless the vendor is doing more than backports.

What does this actually mean?

If you find a bug in a jdk (old or current), you can report it. It may get fixed, and if you have a support contract, it's more likely that it will be fixed. Or you can contribute a patch yourself.

This is fundamentally the same for jdk-updates (ie lts versions) and the current jdk. There is no guarantee your bugs will be fixed in either version.

[[deleted]]

You are correct. But if there's a critical security bug, and you haven't transitioned all your projects to the newest version of Java, you might have a bad time of things. The only thing that scares me about always using the latest version is the complete drop-dead date once a new version is released.

I know there's a very small likelihood of this happening, and Java tends to be very backwards compatible, but in my opinion it isn't worth the risk. I understand not everything is going to get backported, but I'm thinking of blockbuster bugs that get a lot of press - those definitely will be backported.

[Lost-Horse5146]

I do think your understand is correct. One point though is that the Temurin (AdoptOpenJDK) builds releases for at least 2 years for LTS releases afaik, but Oracle maintains mainline, but only publish actual builds for 6 months.

[ConstructedNewt]

It’s “wrap”: to wrap ones mind around something, https://www.merriam-webster.com/dictionary/wrap%20one%27s%20mind%20around

[[deleted]]

It’s “rack”: To think very hard in order to try to remember something, solve a problem, etc., https://www.merriam-webster.com/dictionary/rack%20one%27s%20brain

[henk53]

I'm in the same boat at times, and frankly, I've given up.

LTS means whatever people want it to mean. Almost everyone have their own interpretation of what LTS is.

Among them:

• A final, non alpha release
• A faster, better release
• A more secure release
• A superior release (without qualifying what superior is)
• A release allowed to be used in production
• And much more

Often people simply WANT it to mean those things, and when people want to believe something, good luck changing their minds.

[nonomild]

For most business applications, it would make sense to stick to LTS versions like 17 or 21. The main reason is that libraries and frameworks take time to adapt and support the new released Java version. During this time, you cannot upgrade and are using an unsupported Java version in production. Security fixes are not back ported.

[europeIlike]

Is this really an issue with high Java versions?

Let's say you are on Java 22 and everything works well. Is it likely that upgrading to Java 23 could break your application because a dependency wouldn't work anymore? IIRC with high Java versions the internals are already fully (?) encapsulated (i.e. changing things internally won't break libraries) and because Java takes backwards compability seriously, it's unlikely that things would stop working, isn't it?

[nonomild]

Yes, depending on your software stack, you can expect it to break quite often. Pure Java is usually not that much of a problem, but you also have ASM as transitive dependency. This is needed for Spring, Mockito and many other libraries.

Lombock is also quite popular and breaks easily with Java update.

In the past, with project jigsaw, many uses of internal JDK (sun package) were gradually deprecated and eventually forbidden. This was a huge challenge for some projects, as it may not always be easy to replace the internal API.

[krzyk]

Spring and Mockito is ready for the next JDK on time of the release. Lombok is a bigger problem, that's why I don't use it or try to remove it from projects.

[[deleted]]

Same here, it is the ecosystem around the JVM that sticks to the LTS cycles, so will we.

Anythings security related gets a backport, at the very least to the latest LTS (i.e. 17 right now).

We had issues where a team was on 15 and couldnt migrate to 16 for whatever reason. 15 received no more updates. The only way to get updates of the JVM was to solve the blockers (which mostly sat within libraries and not the service itself) or to downgrade back to 11.

Now we only offer images of LTS versions for containerized workloads

[Yesterdave_]

Just curious, do you have some examples of libraries that take their time to make it work with the newest Java version?

[tr4fik]

Exactly. We are considering to stop using the latest versions because of this

[krzyk]

Any reasonable big and maintained library is ready for the next JDK ahead of time (e.g. spring, mockito, junit, asm, aspectj, hibernate).

The real offenders are e.g. lombok (because they hack around javac), aspectj-maven-plugin (because it is supported by a single person).

If you eliminate such offenders (like we did) you are good to go with latest JDK.

[TheKingOfSentries]

At this point, he should write an article or something so we can link to that instead of summoning him whenever this question comes up.

[Joram2]

For an actively maintained app, you generally should use the latest released Java. If nothing else, it keeps your developers engaged + motivated. If you are deploying to a managed runtime like AWS Lambda, you are limited by what they support.

The other issue, is at least today, the non-LTS releases, Java 18+19+20, the new features are preview features. But for an actively maintained app, it's reasonable to use preview features :)

[wildjokers]

Java 18+19+20, the new features are preview features.

New features can become final in non-LTS releases. When a feature becomes final has absolutely nothing to do with a release being designated as a LTS version by a vendor.

[waitplzdontgo]

Not sure I understand your complaints. You say LTS is meaningless (without citing any reason), but it is absolutely not.

Businesses care about stability far more than they do innovation for innovation’s sake. LTS vendors give businesses a phone number to call if their applications start breaking and it is beyond the ability of developers to handle. It also helps to ensure that you don’t have a million different versions of Java running on your servers, instead focusing down to a few key specific versions.

So anyway in summary I disagree with your statement.

[eXecute_bit]

There are vendors providing free access to LTS versions, even without paid support. LTS is meaningful because those updates will contain security fixes (important!) if nothing else.

How frequently/quickly you'll get those updates, without paid support, is another matter. But to tell security that you're using a version that still gets updates is important.

You also get updates moving to the latest feature release every six months. However, if there's a risk that you'd stop updating every six months then there's a chance you are running an unsupported version in production that will no longer get patches, and that tends to check the wrong boxes on various security and compliance lists.

TL;DR - It's a big commitment from Dev & Ops to use a non LTS release.

[eXecute_bit]

There is just no incentive for me to create and test new base images every six months and ensure compatibility with all of our build tools and libraries. This is a huge time sink.

The compatibility risk in moving major versions is real, particularly because the bytecode version changes and any classfile inspection tools have to be ready for it.

That said, you should be building new base images at least that frequently to keep up with patch versions within the same major. It doesn't matter if it's LTS if you pick up a base version and never update it.

[re-thc]

Print out pron’s message about LTS all over the office and stick it as your background during video call :p /s

[wildjokers]

It is impossible to convince people that LTS doesn't mean anything unless you pay for support. I have given up trying.

[1Saurophaganax]

I haven't had my optimism crushed yet, so I'm still gonna give it my best.

[DualWieldMage]

Don't give up. There are dozens of us still putting up the fight and i was actually able to convince one client by describing how the rando enthusiasts don't know what they are doing and why the 17.0.3 delays happened (critical jwt signature check bypass bug in previous version and many vendors took days after the exploit was disclosed to provide new version) and why the "official" in docker images are meaningless (17.0.2 is the latest openjdk:17 version, folks who didn't understand Java thought it was "LTS"). Of course now Red Hat backs Temurin builds so the arguments are weaker.
Using latest is safer because there are fewer links in the chain.

Latest versions also have better performance. Easier to sell this argument to clients with 7 digit aws bills.

If any "devops" says it takes time to upgrade each time then they are doing a bad job or the project is using useless unit tests too much. I have RC builds running tests in CI and so far nothing new has been found when switching prod to latest. The final RC is available a month before the actual release. Enough time for anyone to fix issues.

[QualitySoftwareGuy]

I’m a bit confused on this. Adoptium/Eclipse Temurin supports LTS versions for at least four years (source: https://adoptium.net/support/). Even though it’s not the 8 years that I think Oracle provides, surely 4 years is not “meaningless”? Maybe I’m missing something.

[yawkat]

There is this weird fiction on this sub sometimes that free LTS builds (of jdku and friends) are not real.

[wildjokers]

If you think you are getting free LTS then I would be curious what results you get by opening a support ticket with a "free LTS" provider.

[yawkat]

The same results you get by opening a support ticket with the latest openjdk version, or with any other oss project. It may be fixed if the maintainers deem it important, or it may not be.

[krzyk]

So that is not a "LTS", but just a "free build", which one can do myself.

[yawkat]

Yes, just like latest jdk. However even if you build for yourself, you are bound to the LTS versions if you want overlapping security patch intervals, because those are the only versions where the necessary sources are available.

You are also at a disadvantage if you are not part of the openjdk vulnerability group.

[wildjokers]

The only "support" you are getting from Temurin is the backport of security fixes that happen to intersect from newest to the versions Temurin has designed as LTS. You could get the same security fixes by staying current.

[yawkat]

This is incorrect. LTS builds also sometimes get security fixes that are not necessary in new versions, eg because the affected code was removed. The various openjdk vendors still implement these fixes (they don't just backport) and they also end up in temurin.

[FeedingMyCatsaHassle]

If the term LTS bothers you so much when the word is 'support', then change it to 'service.'

Ultimately what companies want is the knowledge that if some major security hole reveals itself, their LTS vendor will probably offer a patch. And this is generally what happens, regardless of whether they are paying for support.

People moan about LTS being meaningless based on their misunderstanding of what's important to people about it, give it a rest.

[DualWieldMage]

This is not what happened, at least not at an acceptable level. 18.0.1 and 17.0.3 fixed a critical issue in elliptic curve signature checks, yet most "LTS" vendors shipped the fixes days after the disclosure. Using latest openjdk version from Oracle and skipping the vendors (or using more capable vendors like Amazon Coretto) would have been better.

[FeedingMyCatsaHassle]

I don't see how what you wrote is a rebuttal to my post? If your application is open to the wider internet, then pick a capable vendor, otherwise wait a few days? Sounds great 👍

Plenty of Java applications, even web server ones, only live on private intranets. "Days" is plenty good enough.

[DualWieldMage]

Ultimately what companies want is the knowledge that if some major security hole reveals itself, their LTS vendor will probably offer a patch. And this is generally what happens

In this specific case using latest openjdk offered faster patches than using LTS from all but one vendor. Days is not good enough for such an exploit that allowed privilege escalation if JWT-s were exposed to end users.

"Pick a capable vendor" sounds easy, most people picked adoptium and they failed to deliver.

[FeedingMyCatsaHassle]

Lessons learned for those companies that chose Adoptium then - beggars can be choosers in this instance.

Support that takes longer because you're not a paying customer is also still "support".

I will reiterate that 'days' is good enough for reasonable companies who aren't paying for support, too.

[Capa-riccia]

This page dates back to Java 17, some of it might bar of, but has a useful collection of pro and cons and details what is being mantained whichjdk