An agile Java standard — wishful thinking or not?
Simon Ritter, Deputy CTO at Azul Systems and alternate representative on the JCP EC wrote in a blog post after JCP executive committee’s first face-to-face meeting that “the JCP will require some substantial changes to the processes it uses” to ensure that an agile Java standard is possible.
Last week was one of the three face-to-face meetings that the JCP executive committee (EC) has every year; after the meeting, Simon Ritter, Deputy CTO at Azul Systems and alternate representative on the JCP EC, wrote in a blog post that one thing which has been on the minds of the JCP EC for some time is how the standardisation of Java SE will work in the future.
Before & after
The JCP paved the way for transparency and marked the beginning of “an open process for developing the definition, through standards, of Java platforms, APIs and technologies,” Ritter pointed out in his post. Before J2SE 1.4, Java was developed internally and Sun made the decisions with regard to both features and changes.
A decade ago, Sun open sourced their implementation of the JDK, a decision which meant that “the Java community now has much greater visibility of the development of the Java platform with frequent early access builds being made available.”
Towards a more agile Java standard
Ritter opined that JDK Enhancement Proposals (JEPs) (used to define changes to the JDK) “are an excellent way for finer grained specification of changes, either to the core Java SE platform, or the encompassing JDK” and added that the idea is to use them “as a way of having a more agile (and thus modern) way of delivering changes to Java.”
The Deputy CTO of Azul Systems explained that even though the fact that individual JEPs will be developed in isolation from other JEPs will enable developers to “take advantage of features as soon as they are ready,” the following problem remains: how will this approach work in practice?
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).
Furthermore, introducing “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.”
Ritter concluded that some changes will have to be made to the processes the JCP uses otherwise the idea of making an agile Java standard is unlikely to materialize.