Following on from the confirmation of Plan B, with the delay to a number of JSRs and eviction of both the Lambda project as well as collection literals from Project Coin, it's interesting to take a step back and see how a change makes it into the Java environment. It's not as simple as you think.
From Idea to Implementation
“Ideas are easy; execution is everything” is a common refrain, but is especially true of changes to the Java language. The core Java environment is defined by two volumes; the Java Language Specification and the Java Virtual Machine Specification. Part of the stability of the Java environment is that these tomes have rarely undergone changes; instead, extensions to the Java environment have been done with new APIs (or, in the case of IO, new new APIs). The two main language changes have been the introduction of inner classes and generics, neither of which were backwardly incompatible at the outset – though the bytecode version number has inexorably crept upwards as new features like annotations were introduced.
Getting a change into the Java language will result in modifications to one or both of these books, which in itself is a gargantuan task. JLSv3 is 647 pages, with syntax taking up only 12 of those pages. So adding a new syntax (for collections literals, diamond operators, try-with-resources blocks etc.) is much more than just a couple of updates to the language grammar.
Consider the “Strings in Switch” proposal of Project Coin. This permits literal strings to be used, as well as literal numbers and characters. All you need do is modify the syntax for the switch statement to include a literal String, right?
Joeseph Darcy gave a presentation at JavaOne on the state of Project Coin, and used the above example as a way of highlighting the fact that it isn't just a simple change. The above three columns of text, highlights the amount of detail that is necessary to follow when filing a JSR. The example section is easy enough; and the specification is a handful of lines. But much of it refers to the compilation mechanism (in other words, how it translates it to runtime code in an efficient way as possible), with some other references and compatibility notes.
It turns out that doing the translation in the obvious (naive) way would be very inefficient. Instead, what happens is that the String's hashCode() is calculated at the onset, then a traditional switch block is used to step over the possible hashCode() values, followed by a serial test-for-equality over the Strings. Though this may not seem the most obvious way of solving the problem, the fact that String is final, and the fact that hashCode() doesn't change, means that the JIT will be able to in-line many of the otherwise dynamic calls in order to gain optimum efficiency.
The translation has to be tested (with both positive and negative cases) – whilst the implementation is interesting, the majority of the code changes are associated with the testing. Below is a screenshot of the code behind the implementation, with the first column and a half highlighted as being the implementation of the translation, and the other three and a half columns representing the test cases that go with it.
For more background, read the presentation on Project Coin, which covers this aspect and more. But how and what is this document anyway?
Java Specification Requests
The key way into the Java libraries (or even changes to the JVM itself) starts with a Java Specification Request or JSR. Each JSR gets given a number; the oldest ones therefore have the smallest numbers. The oldest is JSR 1: Real-Time Java, which concluded some 8 years after its original inception. Not all of them make it; JSR 2: Boundary API was withdrawn less than a year later, whilst JSR 3: Java Management eXtensions was turned around in a year. There's a list of all JSRs (or browse by stage).
A JSR needs to have a clear purpose, be sponsored by a team lead or corporation, and form an “expert group” to discuss the various pros and cons of the solution as it goes through. Some of these are merely white-washing other JSRs; for example, the Java EE JSRs are largely just a set of pointers to other JSRs (which individually define Servlets, JSPs and so forth). Thanks to an on-going disagreement about the availability of the Java TCK, the Apache Foundation have voted against some recent Enterprise Specifications such as Java EE 6 – though ultimately, Sun was the only one with a veto vote on board the JCP.
A Java Specification Request has to follow a number of pre-planned steps when it's created:
- Instantiation, whereby a new specification is created (using a template) and then submitted for consideration
- Early Draft Review, whereby a group of experts is convened and set out to complete a first draft of the specification
- Public Draft, whereby anyone with an internet connection can read and comment on the specification
- Final Approval, whereby the executive committe get to vote on the specification, and if approved, becomes an accepted JSR
There are strict timelines on the JCP; each stage has a variable timeline between 30 and 90 days to complete. There are then a couple of cooling-off periods during which voting can occur (that take a couple of weeks to get through to completion) so just navigating the process is a timely consideration. This didn't deter Bob Lee last year from putting forward JSR 330: Dependency Injection for Java in an ambitious goal to add annotations to Java, ahead of the Java EE 6 specification, in less than five months.
If you blinked, you might have missed it. JSR 330, Dependency Injection for Java, completed the shortest development cycle of any Java Specification Request on record within the Java Community Process (JCP) program, a feat that looked only theoretically imaginable on paper until Bob Lee proved it could be done. As co-Spec Lead of JSR 330, Bob wasn't focusing specifically on agility when he pushed the envelope. "While I'm glad JSR 330 executed quickly, I'm even prouder of our specification's quality. I think we raised the bar," he says.
Bob and his co-Spec Lead Rod Johnson hand-picked representatives from across the entire dependency injection community to include in the JSR 330 Expert Group. To enhance rapid development, he kept the group small. Having a publicly-readable mailing list reduced the pressure to include all comers in the official Expert Group. Excluding the Spec Leads, only one expert from each organization was allowed to participate.
By having small focussed group of experts, and a widely-readable public mailing message, they were able to push out both the early review and draft review concurrently, shortening the theoretical time limits. The important thing was keeping it open and being agile, as well as using a version control system to manage the documents, which facilitated understanding changes rather than being presented with a massive word document.
However, the advantage of a closed expert group meant that when issues arose, the expert group could collaboratively resolve the problem before presenting a unified front to the public. Having a split is an essential part of avoiding having too many experts pulling in different directions.
Finally, JSR 330 trailblazed a new approach to JSRs; using standard licensing. It almost resulted in an impasse:
For example, the Expert Group and Sun almost reached an impasse over, of all things, the specification license. The Expert Group wanted to use the same, well-known Apache license that we used for the Reference Implementation (RI) and Technology Compatibility Kit (TCK). Bob says, "I pushed hard because I felt that future JSRs, not just JSR 330, should be able to use the Apache license for their specifications." However, Sun claimed that the JSPA prohibited the Expert Group from licensing their intellectual property (IP) to any implementation that hadn't yet passed the TCK, citing section 5.B of the JSPA.
In the end, the RI and TCK were published under dual licenses, following both the JSPA and bringing the Apache license to use for all to see.
Wither JCP?
There has been no word yet on whether the JCP will exist as a standalone organisation as it was, or whether it will be spun off to an independent entity. Prior to the take-over of Sun by Oracle, there was widespread call for the JCP to become more neutral (like the Eclipse or Apache foundations), including Oracle as well. However, now that Oracle has the upper hand (and more importantly: the veto over the JCP) it's less likely that Oracle will have the same opinion as before.
Already one community has imploded; the OpenSolaris community is evaporating and the governing board resigned. Will the same happen to the JCP? Oracle has made no formal plans as to whether to keep the JCP as is or reform it in some way (or even abandon it completely). Ian Skerrett, Marketing Director at the Eclipse Foundation certainly hopes so:
However, their was no mention about building open source communities or reforming the JCP. My impression is that Oracle will act as a software vendor that uses open source for better product delivery but Oracle will remain very much in control.Obviously, I am a big believer of independent vendor neutral open source communities, so this is disappointing. I think Java would thrive under such a structure.
Time will tell what happens to the JCP. There have been rumours of talks behind the scenes about the JCP, but no news is coming out until it's all decided behind closed doors:
Thomas Kurian [Oracle Server technologies head] told press at JavaOne that Oracle has made a number of proposals to the JCP about its future that are under discussion with the executive committee. What do the proposals say? Kurian wouldn't specify. "Until we get a resolution we are not going to comment publicly," Kurian said.