Life after Java 9: Will you miss the old version numbering scheme?
© Shutterstock / Tang Yan Song
A lot will change in the Java world now that JDK 9 has been released. Oracle has proposed a new version numbering scheme in order to emphasize the time-based releases and to make it easier to figure out the release date of any particular release. In short, there will be no Java 10 — instead, we’ll have 18.3 (March 2018), then 18.9 (September 2018) and so on. Which scheme do you prefer?
September 21, 2017 was a day to remember — Java SE 9 was released and people couldn’t be more excited about the new version.
— Nicolai Parlog (@nipafx) September 21, 2017
The Java 9 release party in Munich, Germany was a blast — the crowd burst into applause as the new version was released. Java 9 was launched in style in Santa Clara (according to Twitter) but enough about parties.
Post – Java 9 version numbering scheme
It’s too early to think of what’s next since we’re still enjoying the adrenaline rush from the new release but whether we want it or not, some things will change.
Not long ago, Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, proposed that the Java SE Platform and the JDK go from “the historical feature-driven release model to a strict, time-based model with a new feature release every six months, update releases every quarter, and a long-term support release every three years.”
To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form
$YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9.
Donald Smith, Senior Director of Product Management for Java SE at Oracle told us that “the new model will encourage quality because ‘missing a train’ with a feature that is not quite ready means only a six-month delay whereas before it could mean years.”
Nicolas Parlog wrote in a blog post that even though two feature releases per year sounds good, “one problem with
year.month is that it looks like semantic versioning but isn’t — 18.9 might have more severe changes than 19.3, yet the latter incremented the ‘major version’, while the former did not.”
The new scheme — Thoughts
Although the proposal has received positive feedback, the new scheme is a different story. According to Gili Tzabari, “every product that has used time-based version numbers has inevitably dropped the approach (the only exception that comes to mind is MS Word).”
Also, every newcomer has to be taught about this, so they don’t go looking for 18.4. And heavens forbid one release is not on time, so there’s a 18.4 after all. Or the release months change because nobody works over the summer, so x.9 never had any interesting new features. (At least that would reestablish semantic versioning.)
Nicolai Parlog, Radical new plans for Java
Glad to see this happen! I dislike the proposed release number scheme though.
— Stephen Colebourne (@jodastephen) September 6, 2017
10, 11, 12 vs. 18.3, 18.9, 19.3
Stephen Colebourne has written a plea “for sane Java version numbers such as 10, 11, 12”.
My plea for sane Java version numbers such as 10, 11, 12 (not 18.3, 18.9, 19.3). RT if you agree! https://t.co/EjM49rRsmM
— Stephen Colebourne (@jodastephen) September 22, 2017
He believes that even though “the LTS release is important to Oracle and big business, it will be pretty unimportant to the community.” Furthermore, “a year/month scheme is unusual and unexpected.”
Read the entire plea here.
Stephen proposes that “versions should simply increase incrementally”:
March 2018 — v10
September 2018 — v11
March 2019 — v12
September 2019 — v13
and so on.
His tweet gathered a lot of comments and retweets. Uwe Schindler (we recently talked with him about the state of Java) supported Stephen’s plea and explained that he’d rather see Oracle keep version numbers. “I’d say in March 2018 comes 9.1 as I understood it when new version scheme in Java 9 was added,” Uwe added.
Srikanta, a former IBMer opined that the idea of two releases per year “will make it cumbersome” in four-five years.
Some other reactions include:
Assumptions are this new versionscheme will be stable for ever, see https://t.co/pwBC2Y3vRf
— Robert Scholte (@rfscholte) September 23, 2017
Alternatively, go 10,11,12 etc until they catch up with the year (has advantage that we can decide 10,11,12 is good enough at v24 in 2024)
— Stephen Connolly 🚳 (@connolly_s) September 23, 2017
Nicolai Parlog also thinks it’s a good idea “to stick to the current scheme and increment the minor version with every feature release unless it contains considerable language/JVM changes, in which case the major version gets bumped,” according to his latest blog post.
If all that’s no good and the year needs to be in there, I have a final suggestion: Go with
year.increment(18.1, 18.2, …) like JetBrains does for IntelliJ et al. This would give more leeway for adding, omitting, or rescheduling releases or the entire release schedule without baking that into the version.
This is not the first time Oracle has changed the version numbering scheme and it’s definitely not the first time developers have found it confusing.
lulz. “To avoid confusion”, Java is adopting the most confusing version numbering scheme I’ve ever seen: http://t.co/qligveIHTc
— Bokmann (@bokmann) June 17, 2013
— Søren Lund (@slu) May 18, 2013
Would someone PLEASE put Oracle/Java out of their misery? “Java SE – Change in Version Numbering Scheme” http://t.co/96ovNuqNSF
— Matt Schultz (@schumatt) May 14, 2013
This might help you see it differently:
Donald Smith urged Java users to “think of 9->18.3 as you might 8->8u20, and 18.3->18.9 as you might think of 8u20->8u40.”
Don’t think of 9->18.3->18.9 akin to 6->7->8. Think of 9->18.3 as you might 8->8u20, and 18.3->18.9 as you might think of 8u20->8u40.
— DonaldOJDK (@DonaldOJDK) September 25, 2017
He explained that those who look at the release history of 8->8u20->8u40 “will see the six-month pattern already well established…” and added that “the new way means spec/API changes can be made leading to more meaningful updates…”
..and more importantly, don’t think of this as meaning every six months you have to implement a lambda or a jigsaw…
— DonaldOJDK (@DonaldOJDK) September 25, 2017
Nothing is set in stone — not yet at least
However, right now the new version numbering scheme is just a proposal. As Falk Sippach pointed out in a recent interview, “no one knows whether it really is going to go this way.”
On the one hand, I think it is a good idea since small features will be shipped fast this way. On the other hand, the scope of releases will be quite small, feature wise. The differences between some versions like 2018.9 and 2019.3 will be rather small, consisting mostly of details. Developers need to adjust their way of thinking about Java. New Java versions won’t be big events anymore, unlike those we were looking forward to up to now.
Read the entire interview here.
If you want to meet Donald Smith and find out more about the current status of Java SE, don’t miss his keynote at JAX London. Donald will give a quick overview of how OpenJDK plays a key role in the Java SE ecosystem, followed by details of the proposed plan and its current status.The keynote will be followed by a panel whereby the two key proposals – increased cadence and Oracle produced OpenJDK builds – will be discussed for pros and potential gotchas. Panelists include Daniel Bryant, Stephen Colebourne and Peter Lawrey.