Is An Agile Java Standard Possible?

During Open Source Week Simon Ritter wrote about the Java Community Process, exploring its history and strengths. In another post, written for Azul’s blog, he followed up with how the JCP might evolve in the future – we publish it here to make sure you see how Java’s evolution is evolving (yes, meta).

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).

Release	JSR	EG Size	Date
Java 2 SE 1.4	59	8	May, 2002
Java 2 SE 5.0	176	18	September, 2004
Java SE 6	270	19	December, 2006
Java SE 7	336	4 + 2 Oracle	July, 2011
Java SE 8	337	3 + 2 Oracle	March, 2014
Java SE 9	379	3 + 2 Oracle	Early 2017

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.

This is where Simon’s post ends but I want to amend parts of another one he wrote more recently that follows up on the idea with anecdotal data.

The theme for this presentation [editor’s note: at Voxxed Days Bristol] was the same as a blog post I’d written earlier this year [the one you just read]. In my presentation, I discussed the ways in which the standards for the core Java platform have been developed in the past (primarily through the JCP) and how this might change in the future.

What was most interesting, and revealing, to me was when I did a quick poll of the audience. Assuming we were to switch to an agile approach for developing and releasing new features for Java how frequently would people want this? I started with the idea of a quarterly release, which got less than a handful of votes. The majority of the audience seemed happy with the current rate of release. Obviously, this is only a small sample size, but I suspect it’s fairly representative of developers in general.

I discussed this point with some people afterwards, and the general opinion was that sure it would be good to have access to new features more quickly, but the downside is the amount of testing, certification and support implications that agile development of the platform generates.

During my travels, I will certainly be gathering more data on this question because it may well be that an agile approach is appropriate for applications, but not so desirable for the core Java platform. Let me know whether you feel strongly one way or the other.