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.
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.
Contents
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.)
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:
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.
Déjà-vu
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.
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.”
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…”
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.
[“Source-jaxenter”]
