May 27, 2011, 11:46 AM —
The Java Community Process may get a welcome and much-needed breath of fresh air if a new proposal from Oracle is approved.
The proposal, entitled JCP.next JSR 1, which is actually Java Specification Request 348, would see a reorganization of the existing Java Community Process to make the JCP a more open environment in which developers can work.
According to the JCP Program Office, JCP.next JSR 1 (JJ1) "will focus on changes to the JCP Process Document in the following areas: transparency, participation, agility and governance. The Process Document describes the formal procedures used in the JCP program."
JSRs, by the way, are defined as "actual descriptions of proposed and final specifications for the Java platform."
Oracle also intends to submit JSR 349, aka JCP.next JSR 2 (JJ2), "soon." JJ2 will focus on modifying the Java Specification Participation Agreement (JSPA). "The JSPA is the membership agreement of the JCP program [that] describes each Community Member's rights and obligations when participating on the development of Java technology specifications," according to the JCP Program Office.
The JSPA is also the part of the JCP that was the root cause of the Apache Software Foundation's (ASF) departure from the JCP last December.
At the time, Apache was aggravated that Oracle, which is the sustaining member of the JCP, had never granted a test compatibility kit (TCK) license to the ASF's own Java implementation, Project Harmony, due to specific incompatibilities in the TCK's license. Without the TCK, Harmony cannot be tested and certified against the Java standard. This effectively reduces the potential user base for Harmony, which the ASF claims is pretty much the whole reason Sun Microsystems, the original sustainer of Java, inserted the incompatible language in the first place.
"Java specifications are proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses," according to the ASF statement at the time. That spec lead being Oracle.
Fixing the JSPA, then, is expected to be a highly contentious issue. It will be very interesting to see how JJ2 will propose to fix the openness issue that Oracle claims to want to resolve, yet keep Oracle firmly in command of Java (which everyone on the planet knows Oracle really wants).
In the meantime, JJ1 will establish an Expert Group made up of a lot of industry vendors (like Google, HP, Red Hat, Intel, Nokia, Samsung, RIM, and IBM, among others) to put together a new JCP Process Document
- "Requiring all Expert Group (EG) operations to be carried out in public forums.
- "Increasing the transparency of the recruiting process for Expert Group members to ensure that all applications are fairly considered.
- "Exploring ways to enable all JCP members to participate in EC activities through public teleconferences, meetings, e-mail aliases and discussion forums.
- "Determining how to disclose TCK testing process results, for example publishing lists of compatible implementations on jcp.org and by removing any barriers to the disclosure of test results."
It's not clear what's the catalyst for this change. It could be something that Oracle's has in mind all along, and perhaps the ASF's departure was a clear ringing of the clue phone.
Another clear indicator might be this graph I found that outlines the number of JSRs submitted over the years.
The graph, part of a blog entry written by Java developers David Nuescheler and Bertrand Delacretaz when Apache left the JCP in December, was used by the authors to illustrate the point that Java has become a very mature project and there are still plenty of places developers can work on new Java APIs.
Yeah, but there's mature, and then there's decrepit. I look at the same graph and wonder if the JCP hasn't choked itself by having so many closed or partly closed JSRs as time went by. Certainly the Apache/Sun dispute that started in 2006 didn't help (something Nuescheler and Delacretaz also note).
Oracle may finally be waking up to the fact that developers are indeed working outside of the JCP to get their Java improvements made because the JCP is no longer an optimal environment in which to work. If they are, JJ1 and JJ2 could be a welcome change to the JCP.
Certainly the London Java Community (LJC) is looking forward to it. As the first Java User Group (JUG) to hold an open seat on the Java Standard Edition/Enterprise Edition Executive Committee, the London group is very excited about reformations to the JCP.
"JSR 348 has [JJ1] just been announced which is going to take great strides to open up the JCP, the Expert Groups (EGs) and just the overall ecosystem of standards. We implore you to get involved and send in feedback, whether its to us, your local JUG leader or through [the] official JCP channels...
"The LJC and many other EC and EG members are very firmly in the camp of making JSRs more accessible to everyone. As well as enforcing openness via JSR 348, we also see a very real chance to have each JSR really engage with the community. We're going to try and work with JSR EGs to see how we can raise their profile, make them really easy to access etc. Something along the lines of running a successful open source project is what we're looking at."
The LJC remarks seem to sum up what the rest of the Java community is feeling: get the JCP and its processes more open, for the betterment of all Java.