New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

New Java Version - it's not JDK 1.9

| by Bienvenido David on Nov 30, 2014. Estimated reading time: 3 minutes |

JDK Enhancement Proposal (JEP) 223 is a new JDK versioning scheme to make it easier to distinguish major, minor, and security releases. It's simpler, more intuitive, easier to parse, and aligns with current industry practices, in particular Semantic Versioning. For example, if JDK 1.7.0_65-b20 (7u65) used this new versioning scheme, the version string would be JDK 7.6.15+20 (7.6.15).

In the existing JDK versioning scheme, "JDK 7 Update 65", "JDK 1.7.0_65", and "JDK 7u65" are different names for the same release. To identify and compare releases, a simple pointwise comparison of parsed tokens is not enough, and a fairly sophisticated algorithm is required. The use of the lower-case 'u' is also not an industry standard and is not language-neutral. In the current JDK numbering scheme, minor releases containing changes beyond security fixes are multiples of 20. Security releases based on the previous minor release are odd numbers incremented by five or six. Those not versed in this numbering scheme would think that "JDK 7 Update 60" is 5 releases later than "JDK 7 Update 55" and incorrectly assume the former has more security fixes. This practice of encoding the minor and security versions in one number is not easy to decipher and also results in skipping many versions.

The goals of JEP 223 are: the version should be easy to understand and easy to parse, it should align with current industry practices of Semantic Versioning, and it should be adoptable by existing packaging and deployment systems. The JEP will also provide an API for version string parsing, validation, and comparison. It is not the goal of this JEP to change the version string format used by a previous JDK release.

A version number is a non-empty sequence of non-negative integer numerals, separated by period characters. It does not contain leading zeroes, and matches the regular expression [1-9][0-9]*(\.(0|[1-9][0-9]*))*. The first three elements are $MAJOR.$MINOR.$SECURITY. $MAJOR is incremented for a major release that contains significant new features as specified in a new Java SE Platform Specification. $MINOR is incremented for a minor update release that may contain compatible bug fixes, revisions to standard APIs and implementation features like new garbage collectors or support for new hardware architectures. $SECURITY is incremented for a security-update release that contains critical fixes. $MINOR and $SECURITY is reset to zero when $MAJOR is incremented. A higher $SECURITY value for a given $MAJOR value indicates a more secure release, regardless of the $MINOR value.

A version string consists of a version number, optionally followed by pre-release and build information. The pre-release identifier ea is for an early-access release that's under active development. The build number is incremented for each promoted build, and reset to 1 when any portion of the version number is incremented. The version string with trailing zero elements omitted is called the short version string. The following compares the potential version strings for JDK 9 using the current and proposed formats. Note that existing code that assumes the JDK version always starts with a 1 will no longer work correctly.

                      Existing                Proposed
Release Type    long           short    long           short
------------    --------------------    --------------------
Early Access    1.9.0-ea-b19    9-ea    9.0.0-ea+19    9-ea
Major           1.9.0-b100      9       9.0.0+100      9
Security #1     1.9.0_5-b20     9u5     9.0.1+20       9.0.1
Security #2     1.9.0_11-b12    9u11    9.0.2+12       9.0.2
Minor #1        1.9.0_20-b62    9u20    9.1.2+62       9.1.2
Security #3     1.9.0_25-b15    9u25    9.1.3+15       9.1.3
Security #4     1.9.0_31-b08    9u31    9.1.4+8        9.1.4
Minor #2        1.9.0_40-b45    9u40    9.2.4+45       9.2.4

The JEP was created on October 20, 2014 and is under Candidate status for release with JDK 9. For more information, including a sample JDK Java API, please read JEP 223 and JBS (JDK Bug System) 8061493.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Can't imagine Java 9.2.4! by Richard Richter

Just kidding, of course I can. It would just make the whole "Here at Sun we know how to confuse everybody about our versions" story complete. Here comes 10th major Java version... wait for it... wait for it... yes it's - 9.0.0! (But then we can just skip 9, they did the same for Windows. :-))

Definitely meaningful goal though.

Re: Can't imagine Java 9.2.4! by Charles Humble

Yes please. Anything to get away from this:

Re: Can't imagine Java 9.2.4! by Victor Grazi

I am surprised Oracle didn't change it to Java 11g or Java 12c

Good news by Ben Evans

This is a very welcome change. I recall a discussion with Mark at FOSDEM a few years ago about exactly this subject - so I'm glad the corner cases we discussed are finally getting addressed.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you