Is An Agile Java Standard Possible?

This week we had one of the three face-to-face meetings that the JCP executive committee (EC) has each year. This is only my second meeting of this format; despite my long history with Java it’s interesting to see the way things work from this perspective.

Since the minutes of the meeting have not yet been published I won’t talk directly about what was discussed. However, one thing that has been on the minds of the JCP EC for some time is how the standardisation of Java SE will work in the future.

First, let’s look at how things have worked in the past. The JCP was started in 1998, as a formalised mechanism to allow interested parties to develop standard technical specifications for Java technology (thanks, Wikipedia). This was the start of an open process for developing the definition, through standards, of Java platforms, APIs and technologies. Prior to J2SE 1.4, Sun developed Java internally and made all the decisions about what features to add and what changes to make.

The table below shows the history of Java Specification Requests (JSRs) for Java SE including the size of the expert group (EG) 

There are also a couple of odd JSRs in the 900 range that are for maintenance releases of the specifications, specifically for J2SE 1.4. These are JSR 915, 916, 917, 918 and 923. The idea of these seems to have been dropped subsequently.

Obviously, there is a lot of history that goes around all of this, but it’s quite revealing to see the way the size of the EG has changed. For the first JSR, it was quite small, presumably, because people weren’t sure if, and how, this would work. Java SE 5 and 6 had significant interest, which has since waned. The only non-Oracle entities that have been involved with SE 7, 8 and 9 are Red Hat and IBM. It would seem that the majority of the Java community are happy for Oracle’s Java Engineering Group and the likes of Mark Reinhold and Brian Goetz to make the decisions about what major features to add to Java.

The other significant date in this story is 2007 when Sun open sourced their implementation of the JDK. The OpenJDK project is now the reference implementation for the Java SE standard. This was a smart decision because it means that the Java community now has much greater visibility of the development of the Java platform with frequent early access builds being made available.

What we’ve also seen, starting with JDK 8 and becoming more significant in JDK 9, is the use of JDK Enhancement Proposals (JEPs)  as a way of defining changes to the JDK. Many of these overlap with the definition space of Java SE, but there are plenty that fall outside this (adding a search facility to the Javadocs is a case in point).

JEPs are an excellent way for finer grained specification of changes, either to the core Java SE platform, or the encompassing JDK. The idea, moving forward post-Java SE 9, is to use this as a way of having a more agile (and thus modern) way of delivering changes to Java. The concept is that individual JEPs will be developed in isolation from other JEPs so that, when they are ready to ship, they can be included in the JDK. No more waiting two or more years for a major release to have access to new features. Excellent!

In theory, this is a splendid idea, since developers will be able to take advantage of features as soon as they are ready. However, there are some serious considerations to how this will work in practice.

Having major releases makes developer’s lives simpler in some ways because they know what version of Java source code has been developed under, so which level it will compile at and which version of the runtime it requires. This is not an insurmountable problem at all since all that is effectively changing is the granularity of releases. Rather than having Java SE 8 code and binaries requiring JDK 8 and JRE 8 we have something like Java SE 9.1.3 code requiring the associated JDK/JRE.

However, this leads to some difficult questions about how Java SE will be specified. With the existing JSR system, each major release of Java SE has a complete specification that can be used by anyone to create their own implementation. There is also an associated reference implementation (the OpenJDK) and a test suite (the TCK/JCK). If we start using a fine-grained point release system the way JSRs work will need to change if it is to continue to be used (George Saab, Vice President of Software Development Java Platform Group at Oracle, has already said there are no plans to stop using JSRs to define Java SE). 

As we know, JSRs currently use an expert group to define the specification, which is then published for public review. Assuming that everyone involved votes for the specification to be accepted, the implementation is released.

Including smaller pieces of functionality between major releases means their specifications will need to be added to the JSR to form an aggregate. Having an expert group and public reviews seems a far too heavyweight approach to making this manageable (consider that 90 JEPs are being included in JDK 9).

It seems to me that the JCP will require some substantial changes to the processes it uses (at least for Java SE, but possibly the same approach will be utilised for Java EE) for this to work practically. Let’s hope that it is indeed possible to make an agile Java standard.