Trains, Buses, and JDK Releases
Trains, Buses, and JDK Releases
JDK will be moving to a twice-yearly release cycle. While this seems like a great idea, given the recent rise of containers, it might require changes in the JSR process.
Join the DZone community and get the full member experience.Join For Free
Atomist automates your software deliver experience. It's how modern teams deliver modern software.
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 23 rd 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-month 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 microservice architectures. If anything, I think this change to Java platform development will encourage the use of microservices 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.
Published at DZone with permission of Simon Ritter , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.