Trains, Buses and JDK Releases
Sep 7, 2017 | 5 MIN READ
Sep 7, 2017 | 5 MIN READ
You wait three and a half years for a JDK release and then three come along in the space of a year (thus the reference to buses in the title of this post).
It’s now been officially proposed by Mark Reinhold, Chief Architect of the Java Platform Group at Oracle that the Core Java Platform (in the form of the JDK) will be moving to a twice-yearly release cadence. Rather than just restating what’s in the blog post from Mark (and the post on the OpenJDK mailing list) and from Donald Smith (Senior Director of Product Management at Oracle) I thought I’d look at some of the deeper implications of this change.
Firstly, for fun, let’s look at the cadence of previous JDK releases which I’ve listed in the table below (I’ve only covered the major releases, there were plenty of minor ones in between. JDK 1.4.1 and 1.4.2 were probably the most well known).
JDK 1.0 Released on 23rd January 1996
JDK 1.1 1 year, 1 month (13 months)
JDK 1.2 1 year, 10 months (22 months)
JDK 1.3 1 year, 5 months (17 months)
JDK 1.4 1 year, 9 months (21 months)
JDK 5.0 2 years, 8 months (32 months)
JDK 6 2 years, 2 months (26 months)
JDK 7 4 years, 5 months (53 months)
JDK 8 2 years, 8 months (32 months)
JDK 9 3 years, 6 months (42 months)
The shortest release cycle (not surprisingly) was JDK1.0 to JDK 1.1; the longest was between JDK 6 and JDK 7 (a few things delayed this release like the acquisition of Sun Microsystems by Oracle and the disagreement over TCK licensing).
When viewed in light of the current history of releases, moving to a six-monthly feature release seems a tough task to pull off. At no point have we ever come close to this. However, as Mark points out, often the length of time between releases is because the ‘train’ was held up waiting for a major feature to be ready. Turning things around so only what’s ready gets integrated, resulting in the current release in development always being feature complete makes a lot of sense.
I think one of the factors that will also really help to make this idea a success is the recent rise in popularity of the use of containers and the use of micro service architectures. If anything, I think this change to Java platform development will encourage the use of micro services even more. By creating a hard link between the Java runtime and the service running on it, cleanly isolated from the rest of the system by the container, we eliminate the problems that arise from having multiple versions of run times on the same machine and the need to select the appropriate one correctly. The introduction of multi-release Jar files in JDK 9 and the Java linker, jlink are also significant aids in reducing friction for deployment.
Contributing the commercial features currently in the Oracle binary distributions is also a significant move. The intention is to eliminate the distinction between a binary built from the OpenJDK (such as Zulu from us here at Azul) and the Oracle JDK. This is certainly good news for Java users since they will be able to get these features without the current licensing restriction (they are free for development but can only be used with a commercial license in production) and will be available in binary distributions other than from Oracle.
The one thing that was only briefly touched on in the details of this new scheme is how the JCP and JSRs fit into this. The comment in Mark’s blog post was, “It will be made easier if we can reduce the overhead of the Java Community Process…” The idea of a faster release cadence has been suggested to the JCP EC in the past and Brian Goetz talked at the last EC meeting about the idea of six-monthly feature release. Certainly, there has been no suggestion that the intention is to move away from using the JCP and JSRs for the specification of Java SE.
However, the current JSR process will need to be changed. Although, in theory at least, it is possible to push a JSR from creation to completion in under six months I’m not aware of this ever having been tried, let alone achieved. There are a number of significant things that need to be resolved to make this work in practice: timely access to TCKs, what new role the expert group for the umbrella JSR would have and so on. There is a meeting of the JCP Executive Committee before JavaOne in a few weeks. I think this will be one of the more interesting meetings.
One final thought on the new version numbering scheme. JDK 9 introduces a new version number scheme under JEP 223, which uses $MAJOR.$MINOR.$SECURITY. Clearly that no longer applies so presumably we’ll have another JEP to change this to $YEAR.$MONTH.$UPDATE.
It will be interesting to see what new features make it into JDK 18.3.