Concurrent with the release of Java 17, Mark Reinhold, chief Java architect of the Java Platform Group at Oracle, proposed to shorten the Java Long-Term Support (LTS) cadence from three years to two years. The launch of Java 17 just finished the current three-year LTS cadence of Java 11. Acceptance of this proposal seems likely: Fellow OpenJDK downstream distributors Microsoft, Amazon, and Azul are in favor, while Red Hat delivered a "nervous yes, but..."
Reinhold also proposed the two-year LTS cadence on the OpenJDK mailing list, referencing his blog post where he cited a disappointing uptake of non-LTS Java releases as motivation:
Many popular IDEs, tools, frameworks, and libraries support the very latest six-month feature release [...] Developers [...] are frustrated, however, that they cannot use them right away since their employers are only willing to deploy applications on LTS releases [...] every three years.
He sees two advantages in a shorter cadence: the first is quicker delivery of new Java features in LTS releases every two years instead of every three. The second is the increased attractiveness of non-LTS releases that launch every six months.
Oracle expected a significant uptake of non-LTS Java releases in the past. During a Java panel discussion at QCon London 2019, Donald Smith, Java SE product manager at Oracle, made this statement shortly after the release of Java 12:
Our belief is that people will get on the new release cadence with Java 12 and 13. [...] I think time is going to show that getting on the six-month cadence is actually going to be quite doable, very straightforward.
The proposal would create more work for the JDK Updates Project. Oracle would also need to decide how long they intend to support LTS releases under the new cadence.
There appears to be no formal deadline for the acceptance or rejection of this proposal.
Volker Simonis, principal software engineer at Amazon Web Services (AWS), in favor of this proposal, stated:
On behalf of the Amazon Corretto team, I’d like to express our support for the new JDK LTS release cadence proposal. We think this is the right step forward to keep the OpenJDK project vibrant and relevant with benefits for both developers and enterprises. The Corretto team will be happy to help out and take over new responsibilities in the OpenJDK Updates Project if endorsed by the OpenJDK community.
Martijn Verburg, principal engineering group manager (Java) at Microsoft, agreed, as well:
We would also like to endorse the two-year LTS proposal for builds of OpenJDK. Since most of the end-user ecosystem prefers to have the extra stability of an LTS, this is a great way to encourage them with their modernization efforts! Microsoft is willing to commit to helping maintain the various LTS updates projects as they move through their natural lifecycles.
Gil Tene, CTO at Azul, embraced the new cadence, writing:
On behalf of Azul, I'd like to express our strong support for this proposal to move to a more frequent LTS cadence in OpenJDK. In our experience, most production environments [...] require a degree of expected longevity and stability [...] with [...] ongoing bug fixes & security updates but with no other (or absolutely minimal) changes or enhancements forced on them [...]. Designated LTS releases serve this purpose well, offering both stability and a predictable, practical schedule. [...] Azul [...] is happy to help meet the added burden that more frequent LTS releases may create.
Andrew Haley, technical lead open source Java at Red Hat, voiced the lone dissenting opinion:
The most obvious absence in this conversation is that of ISVs and end-users. [...] We should seek input from the broad Java community before making a decision that will affect everyone. From my point of view as an engineer, moving to a two-year LTS cycle is broadly positive. [...] Certifying libraries to run on a new Java release can take months of effort, and no one is going to welcome having to do so more frequently. [...] I don't want us to be releasing frequent "LTS" versions that few people use. That would cause the fragmentation of the Java community we really want to avoid. [...] So, from me it's a rather nervous yes, but.
Further discussion of this proposal seems to have moved behind closed doors; the last reply on the OpenJDK mailing list is from September 21 and the last response to Reinhold’s tweet is from September 15.
Oracle has been working on several long-term Java projects with significant functionality possibly ready for a Java LTS release in 2023: Project Loom, Project Valhalla, Project Panama, and Project Amber. It is unknown if this thinking influenced this proposal.
Community comments
Depends on if they make it backward compatible
by Javier Paniza,
Not a good timing
by Mileta Cekovic,
6 Months support was never workable
by daniel carter,
Depends on if they make it backward compatible
by Javier Paniza,
Your message is awaiting moderation. Thank you for participating in the discussion.
If they want release a Java LTS each 2 year, well, whlle each new release of Java will be 100% backward compatible, that is not the case for Java 11 and 17.
For me, as a Java framework developer, upgrade to latest Java version is traumatic, it's just expend a lot of work to get tittle benefit, apart to be compatible with Java 17. One problem, is that I use some old libraries that are no longer supported (like TL code generator), or to upgrade to latest libraries version that support Java 17 but are plenty of bug that I have to overcome. Lot of work that I would prefer to expend in adding new features to my framework.
If you're not going to be backward compatible then a 10 years cadence for LTS would perfect.
Not a good timing
by Mileta Cekovic,
Your message is awaiting moderation. Thank you for participating in the discussion.
Although 2 years LTS cycle would be certainly welcome in general, I am afraid it is not the right timing.
Seems that all Valhalla, Loom and Panama are all progressing in a way to meet production ready quality for Java 23 in 3 years. Shortening LTS cycle right now is risking that some of them (most notably my favorite, Valhalla) will not meet potential Java 21 LTS release, which would be a big missed opportunity.
6 Months support was never workable
by daniel carter,
Your message is awaiting moderation. Thank you for participating in the discussion.
you spend the first 3 months of a release cycle waiting for all the libraries and your IDE to add support, then to make your changes, test and release to production. Then you have 3 month running on the release and the next non-LTS release comes out and you are out of support. Even worse, there is no way to get on a supported release as you have another 3 months again until your toolset and testing is done.
If they added another 3 month commitment to fix any critical security issues it would have worked.