InfoQ has an excellent writeup on a new proposal from Oracle, “Oracle Proposes Shorter Java LTS Cycle of Two Years”, discussing a proposal from Mark Reinhold to adjust the long-term support release cadence from once every three years to every two years.

All quotes are from the InfoQ article.

From Reinhold’s original email:

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.

There’s a lot of agreement with the change, with Red Hat’s Andrew Haley being the lone dissent:

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.

It’s quite possible that changing the cadence could in fact increase adoption of the LTS releases, but the danger is, as Haley points out, that it creates a lot of extra work for people who create and who use the LTS releases. With that said, though, the LTS might speed up adoption of the new features the new releases include, and that’s hardly a bad thing.

It’s just hard to predict without actually trying the new cadence.

What’s more, there’s always the possibility that if the new cadence is attempted, and the results aren’t as positive as are hoped for, the cadence could be adjusted again.