Version-string scheme for the Java SE Platform and the JDK: Proposal

Back to JDK 10: “Most feature releases should contain at least one or two significant features”

Gabriela Motroc
JDK 10

© Shutterstock / Neungstockr

Two weeks ago, Mark Reinhold offered three alternatives for the new version-numbering scheme. Now it’s time to present the specific proposal. In short, “JDK 10 is a feature release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug fixes, and there is no interim JDK 10.1 release since in this model the next opportunity to add features is JDK 11.” 

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.”

Not many people liked this proposal —to put it mildly— so Mark Reinhold offered three alternatives:

(A) Absolute: $YY$MM, padding the month number with a zero as needed, and $YY$MM.$AGE for update releases, where $AGE is the number of months since $YY$MM.

(B) Absolute: $YY.$M as proposed, without padding the month number, and $YY.$M.$AGE for update releases, where $AGE is as above.

(C) Relative: $N, where $N is the number of half-years since JDK 9 GA (September 2017) plus nine, and $N.$AGE for update releases, where $AGE is as above. ($AGE is more useful than another incrementing counter since it leaves room for emergency update releases without having to renumber subsequent update releases that are already in development.)

SEE ALSO: Version-string schemes for Java SE Platform & JDK: Oracle offers 3 alternatives

He explained that representing the year with four digits instead of two would “lead to even longer version numbers and  zero-padding the month number in (B) so as to be exactly like Ubuntu ($YY.$MM) —with the intention of making it obvious that JDK 18.03 is not an update release of JDK 18—  “would only work so long as we never ship a feature release after September in any particular year” and promised to make a specific proposal soon.


Mark Reinhold’s proposal is “even closer to the current scheme as defined in JEP 223 and it’s less likely to surprise, and should be easier to adopt.”

Version numbers:

$VNUM — The first four numerals are interpreted as follows:


$FEATURE — “The feature-release counter, incremented every six months regardless of release content. Thus the March 2018 release is 10, the September 2018 release is 11, and so forth. Features may be added in a feature release; they may also be removed if advance notice was given at least one feature release ahead of time. Incompatible changes may be made when justified (Formerly $MAJOR.),” according to the proposal.

$INTERIM — “The interim-release counter, incremented for non-feature releases that contain compatible bug fixes and enhancements but no incompatible changes, no feature removals, and no changes to standard APIs. This counter is always zero for the current six-month release model. We reserve it here to leave flexibility for the future, so that some future release model could say that JDK $N.1 and JDK $N.2 are compatible upgrades of JDK $N. Leaving this counter at zero for the current model has an additional benefit in that it increases the degree to which version numbers continue to reflect, roughly, both compatibility and significance. (Formerly $MINOR.)”

$UPDATE — “The update-release counter, incremented every three months for compatible update releases that fix security issues, regressions, and bugs in newer features. Thus the April 2018 release is 10.0.1, the July release is 10.0.2, and so forth. (Formerly $SECURITY, but with a non-trivial incrementation rule.)”

$EMERG — “The emergency-release counter, incremented only when it’s necessary to produce an emergency release to fix a critical issue. Using an additional numeral for this purpose minimizes the disruption to both developers and users of in-flight update releases.” (amended)

Since $FEATURE is incremented twice a year regardless of release content and $UPDATE is incremented every three months (for each feature), it’s clear that “this is primarily a time-based scheme.”

We do expect most feature releases to contain at least one or two significant features, and never to ship interim releases under the new release model, so in practice this scheme will often be very similar to a compatibility- or significance-oriented scheme like that of JEP 223. JDK 10 is a feature release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug fixes, and there is no interim JDK 10.1 release since in this model the next opportunity to add features is JDK 11.

Mark Reinhold

Version strings

Reinhold explained that “the overall format of version strings is unchanged. A version string is a version number, $VNUM, optionally followed by pre-release, build, and other optional information.”

Optional information alternatives:




$PRE = a pre-release identifier (e.g., `ea`)

$BUILD = a build number

$OPT = optional build information.

He also proposed that implementors who offer long-term support for a release should use an $OPT string that starts with “lts”, e.g., 11.0.2+13-lts.

System properties

There’s one new property (added to the system properties mentioned in JEP 223): — The GA date of this version, in ISO-8601 YYYY-MM-DD format. For EA releases this will be the intended GA date, i.e., some date in the future. This value is not part of the version string per se, but it will be displayed when useful and can be retrieved via a new method on the `Runtime.Version` API.

What is the purpose of this new property? It’s supposed to help you figure out how old a release is, so that (as a user) you can understand how far behind you are. Reinhold mentioned that “it also reflects the security level of the release: A given GA release contains the latest security fixes if its version date is no earlier than that of any other GA release.”


The `java` launcher will display version strings and system properties as follows, for a hypothetical build 13 of JDK 10.0.1:

$ java –version

openjdk 10.0.1 2018-04-19

OpenJDK Runtime Environment (build 10.0.1+13)

OpenJDK 64-Bit Server VM (build 10.0.1+13, mixed mode)


For a hypothetical build 42 of JDK 11, an LTS release:

$ java –version

openjdk 11 2018-09-20 LTS

OpenJDK Runtime Environment (build 11+42-lts)

OpenJDK 64-Bit Server VM (build 11+42-lts, mixed mode)


This is how you should give your feedback

Your feedback should answer the following questions:

— Bearing in mind that no version-string scheme is ideal, is this scheme acceptable?

— If this scheme is not acceptable then please explain why, and identify exactly what you would change.

Relevant replies will be summarized in about a week, then Mark Reinhold will draft a JEP.

Is the scheme useful in practice?

Stephen Colebourne explained in a message to the OpenJDK mailing list that “there is no overlap between the last v10 update (security) release 10.0.2 and the first v11 release. In order to be protected in security terms developers are required to upgrade to 11.0.0 immediately on release.”

Every single major (feature) release of Java I can remember has caused a problem in at least one of the tools in the stack of the application I was working on. To upgrade to a new Java major/feature version I’d currently need all of these to be ready:

– Eclipse
– IntelliJ
– Travis CI
– Shippable
– Amazon AWS
– Maven
– Maven plugins (compile, jar, source, javadoc, site, etc)
– Checkstyle, & associated IDE plugins and maven plugin
– JaCoCo, & associated IDE plugins and maven plugin
– PMD, & associated maven plugin
– SpotBugs, & associated maven plugin
– OSGi bundle metadata tool
– Bytecode tools (Byte buddy / ASM etc)
– Over 100 jar file dependencies
– Probably something else I’ve forgotten

This means that one cannot upgrade to the new Java version if “just one of these isn’t ready.”

If it takes 3 months for the stack to be viable again (hugely optimistic) the version has just 3 months of life before the whole cycle has to start again. My experience would actually say that 6 months (and 2 updates) is generally the point at which the stack is fully stable and it would be OK to put a system into production. But, the six month point is where you get no more security updates. The logical conclusion is that this is a trap, and you should therefore not attempt to join the eternal upgrade train.

Stephen Colebourne

Read the entire message here. 

There are a lot of questions that have not been answered but the conversation is ongoing. We recently talked with Daniel Bryant about the six-month cadence, the new version numbering scheme, the difference between Java 9 and Java 8, Oracle’s new “target” and more.

Gabriela Motroc
Gabriela Motroc is editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Leave a Reply

Be the First to Comment!

Notify of