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

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.

Continue reading %Is An Agile Java Standard Possible?%

by Simon Ritter via SitePoint