Hi all,

We’ve been remiss in posting our thoughts on our official votes for various Java standards that go through the  Java Community Process (JCP) Executive Committee (EC). So in order to get back into the swing of things we thought we’d start with the all important Java 9 SE vote!

For JSR 379 – Java SE 9 (See full results from all voters) we voted Yes for the JSR Review Ballot with the following comment:

We are very happy with the technical content and have high hopes that it will increase the longevity of Java in the age of containers and smaller devices.

We are disappointed with the relatively late release of this JSR. Since much of the RI and TCK has already been built, it makes it much harder for independent implementations to reach the market in a timely manner.

We see that Red Hat, IBM, Google and Oracle will likely make up the EG and we hope to also see wider participation from other JVM vendors.

In terms of technical merit we’re broadly happy.  There are certainly issues with Jigsaw vs the ‘real world’, which was anticipated and hopefully will be mitigated by further early testing of JAva 9 and some compromises made by both the authors of libraries, frameworks and products and the authors of the Jigsaw module system.  The rest of Java 9 offers up loads of exciting new features including HTTP 2 support, JShell and a host more.

To add some further insight on the other half of our comment, we need to explain the current challenge we have with OpenJDK vs the JCP standardardization process.  In short, OpenJDK is the GPLv2 licensed open source project that is the Reference Implementation (RI) for Java SE.  Oracle and most (not quite all) other vendors create their commercial ‘Java’ releases from OpenJDK.

However, in order to release a ‘Java’ which can be called Java, you must pass the Technical Compatibility Kit (TCK) which is produced as part of the Java Specification Request (JSR). If the JSR is delivered late on in the development of OpenJDK it puts vendors who produce a non OpenJDK based implementation at a massive disadvantage and even puts the vast majority basing their implementations off OpenJDK at a disadvantage in terms of getting their product complaint and to the market.

There’s also no real mechanism for the community to push back against proposed changes via the JCP, as so much work has already been done in OpenJDK. That is, what’s in OpenJDK is effectively fait accompli.  That’s not necessarily a bad thing as OpenJDK generally speaking provides that highly collaborative open source environment which allows for plenty of community feedback and influence (it’s still nominally Oracle controlled, but it’s about as good as you can get given single vendor ownership).

It does place OpenJDK and the JCP at odds though and we look forward to working with Oracle and the JCP to resolve that (there are some early proposals being discussed).

Cheers,

Martijn (On behalf of the LJC JCP Committee)