I think what's confusing to many, yourself included it seems, is not so much LTS but rather the way versions are named. So let's ignore version names for a moment, and see what's changed.
For many years, at least since JDK 7, every 6 months there was a feature release (back then they were called "limited update" releases) containing large new features and significant changes to the runtime. Java users had no choice but to upgrade to those new feature releases because the old feature releases were abandoned and received no security patches. Because these feature releases were occasionally disruptive, this caused problems to those people who just wanted to get security patches.
So change number one was the introduction of LTS, which, for the first time allowed Java users who wanted just security patches to stay on old feature versions and just get patches without being forced to upgrade to a new feature release every six months.
The other problem was that while feature releases could and often did make drastic changes to the runtime, they could not make any additions to the spec. That means that overhauling the JIT compiler or the GC algorithms (or adding a whole new UI toolkit as long as it wasn't made part of the SE spec) were done in those feature releases, they couldn't so much as add a new method to the ArrayList class, as that meant changing the spec. Changes to the spec were only allowed in "major releases", which, as you correctly note, were irregular and far between.
So change number two was doing away with major releases altogether and removing the restriction that the semi-annual feature releases could not change the spec. This meant that, in addition to 50KLOC of internal changes, feature releases could now a method to ArrayList.[1]
Yet another problem -- the most superficial one -- was how versions were named. 7u1 and 7u3 were patch updates, but 7u2 and 7u4 were big feature releases (and again, people had no choice but to upgrade their JDK from 7u2 to 7u4 because the feature version 7u2 stopped getting patches once the new feature version, 7u4, came out). To make matters worse, the version naming scheme was changed in 8, where the big feature releases were named 8u20 and 8u40 (again, 8u20 was abandoned when 8u40 was released), while patch releases were named something like 8u25.
So change number 3 was to make the version names more meaningful, and with major releases gone this was easy: feature releases would get integer names, while patches would get dot names. The version that would have been named 9u20 was, instead, named 10. This most superficial change that was meant to make it easier for people to understand what's included in the release, unfortunately confused people the most. Some companies stopped making the very same upgrades they'd made for many years (because they had no choice) and relied on the LTS service for patches even when it would have been easier, cheaper, safer, and more productive for them to continue upgrading feature releases as they'd done before.
[1]: But did this make the feature release upgrades harder than before? Maybe a little, but not for long. After JDK internals were encapsulated in JDK 16, those who regularly update feature releases report the process easier than for the feature releases in the JDK 8u and 7u era. This isn't so much because feature updates are perfect, but largely because they were particularly problematic in the past, which is why introducing LTS so that, for the first time ever, those who really don't want or need new features or performance enhancements wouldn't have to upgrade.
Oh my goodness, I remember all that now. That horrible naming scheme confused nearly everybody. Yeah, the numbering system that followed helped a lot, but sadly it had consequences too. I’d say thanks for the history reminder, but yikes. :)
Yeah, so I think we underestimated the psychological effect of the version name. On the one hand, the introduction of LTS allowed legacy software systems (and there's a lot of that) were finally able to abandon the old, pre-JDK 11 model, where they had no choice but to follow the 6-month feature release cadence and feature releases were only supported for 6 months, and could finally get only the security patches they needed. On the other hand, software that's under significant maintenance and development (and there's a lot of that, too) came to the false conclusion (sadly, perpetuated by this post) that upgrading to a new feature release is something they cannot do and some have chosen to adopt the new LTS service (intended for legacy apps) even though continuing to follow the 6 month cadence, as they had done for years and years, is the easier, cheaper, and overall better approach for them (made easier still after modules' encapsulation was finally turned on in JDK 16, making backward compatibility better than it's ever been in Java's history).
The change to the names made the old thing look new and scary, and the new thing look safe and easy, even though it's only the better fit for applications that are no longer heavily maintained.
All good points. The question is, is there a way out of this? They tried shortening the LTS period to two years. My sense is that helped the upgrade cycle, but I don’t see many devs upgrading their JVMs more often than that. I don’t know too many who work at companies that have an actual support contract with Oracle. Maybe they handle things differently.
First we need to understand what the problem is and how big it is. The problem is that while some projects (legacy ones) benefit greatly from LTS, others use it despite it being less appropriate for them than using the current version. How big of a problem is it? Well, by sticking to an old version they work more and get less instead of working less and getting more, but that's not the end of the world. If they're happy, that's okay even though they could be happier. For us, the problems start when they ask for more enhancements to be backported, which works against the tip-and-tail model (https://openjdk.org/jeps/14) that makes LTS work: Backporting more hurts both the intended legacy users of LTS, as it increases the risk of patch updates, as well as the intended users of the current JDK, as it would require more resources to maintain old versions. But overall, I don't think the problem is that big.
Now, you say you don't see many organisations upgrading their JDK to new feature releases, but that is exactly what they had done for many years before LTS existed, so obviously they can do it. Furthermore, ever since we turned on module encapsulation in JDK 16, upgrades are easier now than they ever were (i.e. upgrading from JDK 21 to 22 was easier than from 7u2 to 7u4 or from 8u20 to 8u40). So those who want to help companies make the most out of the JDK should encourage them to understand the tip-and-tail model and let them know that many of them would get more out of it, and for less work, than by sticking with an old version and relying on patch updates delivered through an LTS service.
I don't see what Oracle contracts (or contracts with any of the other companies that sell JDK support) have to do with this, at least not directly. The idea of TLS is that for those who run legacy software, it's cheaper to pay for LTS patches than to increase the investment in maintenance, even by a little bit, and so these legacy projects would fund the development of OpenJDK. That's a win-win for everyone.
Regarding LTS, well put! I totally agree with your logic. We are developers, not lawyers. I'm pretty sure we won't reach java versions 50, 75 or 100, because I have a feeling they'll change release cadence and/or versioning in a few years.
P.S. Still, Java is a great language and I wouldn't want to ditch it.
Well, if having 2 versions a year, I might just catch java50, but definitely not the other ones. However, by "we won't reach..." I meant: we, the community of java developers.
I have no idea what the Java team at Oracle plans to do in the future, but I will admit that Oracle has been a remarkably good steward of the language. I really though we had a disaster brewing when they bought Sun, but that hasn't happened at all. Other than the licensing debacles, of course.
(... doing math in my head ...) Java 50 is scheduled for March 2038? That will mean we made it through the Year 2038 bug? Whoa. That ought to be fun.
I think what's confusing to many, yourself included it seems, is not so much LTS but rather the way versions are named. So let's ignore version names for a moment, and see what's changed.
For many years, at least since JDK 7, every 6 months there was a feature release (back then they were called "limited update" releases) containing large new features and significant changes to the runtime. Java users had no choice but to upgrade to those new feature releases because the old feature releases were abandoned and received no security patches. Because these feature releases were occasionally disruptive, this caused problems to those people who just wanted to get security patches.
So change number one was the introduction of LTS, which, for the first time allowed Java users who wanted just security patches to stay on old feature versions and just get patches without being forced to upgrade to a new feature release every six months.
The other problem was that while feature releases could and often did make drastic changes to the runtime, they could not make any additions to the spec. That means that overhauling the JIT compiler or the GC algorithms (or adding a whole new UI toolkit as long as it wasn't made part of the SE spec) were done in those feature releases, they couldn't so much as add a new method to the ArrayList class, as that meant changing the spec. Changes to the spec were only allowed in "major releases", which, as you correctly note, were irregular and far between.
So change number two was doing away with major releases altogether and removing the restriction that the semi-annual feature releases could not change the spec. This meant that, in addition to 50KLOC of internal changes, feature releases could now a method to ArrayList.[1]
Yet another problem -- the most superficial one -- was how versions were named. 7u1 and 7u3 were patch updates, but 7u2 and 7u4 were big feature releases (and again, people had no choice but to upgrade their JDK from 7u2 to 7u4 because the feature version 7u2 stopped getting patches once the new feature version, 7u4, came out). To make matters worse, the version naming scheme was changed in 8, where the big feature releases were named 8u20 and 8u40 (again, 8u20 was abandoned when 8u40 was released), while patch releases were named something like 8u25.
So change number 3 was to make the version names more meaningful, and with major releases gone this was easy: feature releases would get integer names, while patches would get dot names. The version that would have been named 9u20 was, instead, named 10. This most superficial change that was meant to make it easier for people to understand what's included in the release, unfortunately confused people the most. Some companies stopped making the very same upgrades they'd made for many years (because they had no choice) and relied on the LTS service for patches even when it would have been easier, cheaper, safer, and more productive for them to continue upgrading feature releases as they'd done before.
[1]: But did this make the feature release upgrades harder than before? Maybe a little, but not for long. After JDK internals were encapsulated in JDK 16, those who regularly update feature releases report the process easier than for the feature releases in the JDK 8u and 7u era. This isn't so much because feature updates are perfect, but largely because they were particularly problematic in the past, which is why introducing LTS so that, for the first time ever, those who really don't want or need new features or performance enhancements wouldn't have to upgrade.
Oh my goodness, I remember all that now. That horrible naming scheme confused nearly everybody. Yeah, the numbering system that followed helped a lot, but sadly it had consequences too. I’d say thanks for the history reminder, but yikes. :)
Yeah, so I think we underestimated the psychological effect of the version name. On the one hand, the introduction of LTS allowed legacy software systems (and there's a lot of that) were finally able to abandon the old, pre-JDK 11 model, where they had no choice but to follow the 6-month feature release cadence and feature releases were only supported for 6 months, and could finally get only the security patches they needed. On the other hand, software that's under significant maintenance and development (and there's a lot of that, too) came to the false conclusion (sadly, perpetuated by this post) that upgrading to a new feature release is something they cannot do and some have chosen to adopt the new LTS service (intended for legacy apps) even though continuing to follow the 6 month cadence, as they had done for years and years, is the easier, cheaper, and overall better approach for them (made easier still after modules' encapsulation was finally turned on in JDK 16, making backward compatibility better than it's ever been in Java's history).
The change to the names made the old thing look new and scary, and the new thing look safe and easy, even though it's only the better fit for applications that are no longer heavily maintained.
All good points. The question is, is there a way out of this? They tried shortening the LTS period to two years. My sense is that helped the upgrade cycle, but I don’t see many devs upgrading their JVMs more often than that. I don’t know too many who work at companies that have an actual support contract with Oracle. Maybe they handle things differently.
First we need to understand what the problem is and how big it is. The problem is that while some projects (legacy ones) benefit greatly from LTS, others use it despite it being less appropriate for them than using the current version. How big of a problem is it? Well, by sticking to an old version they work more and get less instead of working less and getting more, but that's not the end of the world. If they're happy, that's okay even though they could be happier. For us, the problems start when they ask for more enhancements to be backported, which works against the tip-and-tail model (https://openjdk.org/jeps/14) that makes LTS work: Backporting more hurts both the intended legacy users of LTS, as it increases the risk of patch updates, as well as the intended users of the current JDK, as it would require more resources to maintain old versions. But overall, I don't think the problem is that big.
Now, you say you don't see many organisations upgrading their JDK to new feature releases, but that is exactly what they had done for many years before LTS existed, so obviously they can do it. Furthermore, ever since we turned on module encapsulation in JDK 16, upgrades are easier now than they ever were (i.e. upgrading from JDK 21 to 22 was easier than from 7u2 to 7u4 or from 8u20 to 8u40). So those who want to help companies make the most out of the JDK should encourage them to understand the tip-and-tail model and let them know that many of them would get more out of it, and for less work, than by sticking with an old version and relying on patch updates delivered through an LTS service.
I don't see what Oracle contracts (or contracts with any of the other companies that sell JDK support) have to do with this, at least not directly. The idea of TLS is that for those who run legacy software, it's cheaper to pay for LTS patches than to increase the investment in maintenance, even by a little bit, and so these legacy projects would fund the development of OpenJDK. That's a win-win for everyone.
Regarding LTS, well put! I totally agree with your logic. We are developers, not lawyers. I'm pretty sure we won't reach java versions 50, 75 or 100, because I have a feeling they'll change release cadence and/or versioning in a few years.
P.S. Still, Java is a great language and I wouldn't want to ditch it.
Thanks. The only thing I know about version numbers that high is that I'll be safely retired by then :)
Well, if having 2 versions a year, I might just catch java50, but definitely not the other ones. However, by "we won't reach..." I meant: we, the community of java developers.
Sure, I got that. :)
I have no idea what the Java team at Oracle plans to do in the future, but I will admit that Oracle has been a remarkably good steward of the language. I really though we had a disaster brewing when they bought Sun, but that hasn't happened at all. Other than the licensing debacles, of course.
(... doing math in my head ...) Java 50 is scheduled for March 2038? That will mean we made it through the Year 2038 bug? Whoa. That ought to be fun.
Readers and leaders rhyme, too.
Sure, but do readers and leaders?