Java versioning: Why Java 10 maps to version 18.3 of the JDK
When it comes to Java versioning, things have never been straightforward. Java 2 mapped to JDK 1.2. Java 5 mapped to JDK 1.5. But how did Java 10 end up mapping to JDK 18.3?
Oracle released Java 10 last week. But if you took the time to install the Java 10 JDK and poked around a bit, you'd find out that the Java 10 product was dragging around an 18.3 version label on its JRE and HotSpot server. There's always been a disconnect between the product name and the underlying JDK version, but at least Java 8 matched the decimal increment of the underlying JDK, which was versioned at 1.8. But Java 10 being mapped to 18.3 certainly needs some explaining. So, how exactly did Java 10 become version 18.3 of the JDK?
A short history of Java versioning
Java versioning has never made a lot of sense. The last time it did was back in the late 1990s, when the first full increment product release, Java 1.0, carried the same version number as the underlying Java Development Kit. Similarly, version 1.1 of the JDK was sensibly referred to as Java 1.1.
But things got a little convoluted when Sun released version 1.2 of the Java virtual machine and branded the product Java 2. Java 2 Platform, Standard Edition was further distinguished from its predecessors by bearing the name J2SE, an abbreviation that also distinguished it from the enterprise and micro editions of Java, called J2EE and J2ME, respectively.
One may have thought that J2SE would beget J3SE, which would beget J4SE, which would beget J5SE, but no, it did not. From versions 1.2 through 1.4 of the JDK, the branding was simply J2SE 1.2, J2SE 1.3 and J2SE 1.4.
With the 1.5 release of the JDK, the product name embraced the decimal and just called itself J2SE 5.0, as opposed to J2SE 1.5, as previous releases would have predicted.
Shedding the Java 2 skin
The 1.6 build changed the branding yet again and called it Java SE 6, eschewing the association with the Java 2 Platform and the J2SE moniker. Following the Java SE 6 release, the 1.7 build of the JDK became Java SE 7, and the 1.8 build of the JDK mapped to Java SE 8 -- although, conversationally, they were just Java 7 or Java 8.
Sanity actually returned to the world of Java versioning in 2017 as a $MAJOR.$MINOR.$PATCH naming scheme meant the Java 9 platform mapped to the Java Runtime Environment (JRE) with a 9.0.0 label, but that sensible naming pattern was a one-off that didn't last a year.
The long-standing Java versioning strategy of matching the Java platform's branding to the decimal increment of the JDK was always a bit strange, but a developer didn't have to be told twice in order to understand the pattern. And mapping Java 9 to a JDK with a version 9 label just made sense. So, how did Java 10 end up getting mapped to version 18.3? And for that matter, what happened to all of the missing Java versions leading up to 18.3?
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.
Mark ReinholdChief architect, Java Platform Group
The answer lies in the fact that Oracle has now put the JDK on a six-month release cadence. A new version goes to general availability every March and September, regardless of whether a given feature set is ready for inclusion or not. The new Java versioning scheme now reflects the year and the month in which the JDK was released. Mark Reinhold, chief architect of the Java Platform Group, spelled it all out in a blog post late last year.
"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."
So, the fact that the Java 10 product maintains a version number of 18.3 under the covers reflects the fact that it became generally available in March 2018. In fact, when you invoke the -version switch on the java.exe/sh executable on a Java 10 installation, here's what you get:
C:\java -version java version "10" 2018-03-20 Java (TM) SE Runtime Environment 18.3 (build 10+46) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46)
Compare that to what one would have seen with Java 8:
C:\_jdk1.8\bin>java -version java version "1.8.0_73" Java(TM) SE Runtime Environment (build 1.8.0_73-b02) Java HotSpot(TM) Client VM (build 25.73-b02, mixed mode)
Fortunately, the Java versioning scheme shouldn't change again for a while. So long as Oracle adheres to a six-month release cadence, the new Java versioning scheme should persist for a bit. Oracle has already outlined the release dates for both Java 11 and Java 12, which should brush the Java community right up against the end of the decade.
Java versioning: Future release dates
10.0.0 feature release: March 2018
10.0.1 update release: April 2018
10.0.2 update release: July 2018
11.0.0 feature release: September 2018
11.0.1 update release: October 2018
11.0.2 update release: January 2019
12.0.0 feature release: March 2019
The history of Java versioning is a bit comical when you look back at all of the different ways Oracle and Sun have branded the JDK, but it looks like the new naming scheme will be with us for a while, and using the year and the month of the release as the major and minor increment values really isn't a difficult concept for developers to get used to.
Dig Deeper on Core Java APIs and programming techniques
