JCP Gives Java 7, 8 Roadmaps Greenlight Under Protest

Oracle got its wish and gained approval for the technical roadmaps governing Java Standard Edition 7 and Java 8, but not without hearing the voice of dissent from several prominent members of the Java community.

The Executive Committee (EC) of the Java Community Process (JCP) voted to approve the Java Specification Requests (JSRs) for Java 7 (JSR 336) and Java 8 (JSR 337), based on the technical content of the JSRs. However, based on many of the comments, much of the underlying sentiment amounted to a vote of “no confidence” in the JCP and, by extension, Oracle itself.

The votes for both JSRs were 12 for and 3 against, with Apache, Google and individual member Tim Peierls voting against the specifications. The negative votes and all the negative comments were based on field-of-use (FOU) restrictions on Java and Oracle’s refusal to provide the Apache Software Foundation (ASF) with a Technology Compatibility Kit (TCK) for its Harmony open-source implementation of Java.

Apache had recently threatened to quit the JCP if it did not receive the TCK in question. The open-source software supporting organization has not stated its decision on how it will proceed now that the JSRs have been approved.

However, the vote did prompt one Java SE/EE (Standard Edition/Enterprise Edition) member to quit. Peierls announced his resignation from the executive committee in a Dec. 7 blog post.

In the post Peierls said:

“Today I resigned from the SE/EE Executive Committee of the Java Community Process. I lasted about a year before giving up hope that the ECs would ever do anything meaningful.

“The last straw for me was Oracle's failure to address the ambiguous licensing terms in JSRs 336 and 337 (the Java SE7/8 umbrella JSRs) before the EC had to vote on them. At first I abstained, but I was so dismayed by Oracle's silence that I changed my vote to No, joining the Apache Software Foundation and Google.”

In addition, Peierls said, “Several of the other EC members expressed their own disappointment while voting Yes. I'm reasonably certain that the bulk of the Yes votes were due to contractual obligations rather than strongly held principles. It's not that I'm shocked, shocked that votes can be bought, but it finally made it clear to me that my vote was worthless.”

Six committee members voted “yes” with no comment on the vote. These were Oracle, HP, Ericsson, Fujitsu, VMware and Intel. Six others – SAP AG, IBM, Eclipse, Red Hat, individual member Werner Keil and Credit Suisse -- voted “yes” with comments about the TCK situation. Not only did members complain about the field of use issue, but also about the modularization strategy for Java, which some think should include OSGi – the Open Services Gateway initiative.

“While we support the technical content of this JSR, Google is voting no because of its licensing terms,” Google said in its comment on the vote. “It would be wrong to condone the inclusion of field-of-use restrictions in a TCK license (which violates the above resolution and the JSPA) by voting for this JSR. We were initially reluctant to vote no because we do not want to delay progress of the Java platform. But this concern was made moot by Oracle's statement at the JCP meeting of 10/4/2010 that they intend to move forward with the release outlined in this JSR with or without the approval of the JCP.”

In its comment SAP said:

“While we are disappointed that Oracle has decided to deny Apache a TCK license for Java 7, SAP's vote is strictly based on the technical merits of the Java 7 specification, not on its license terms. While we believe it is important for Java 7 to proceed now, we want to express our disagreement about Oracle's decision regarding the TCK for Apache. The reason that was provided to the EC was that Java compatibility could no longer be enforced with code shared under a permissive open source license. As the new steward of the Java language, we respect Oracle's right to license their intellectual property under terms that support their strategy of how to evolve the Java ecosystem. However, we believe that the additional potential for innovation in open source communities outside of OpenJDK well offsets the risks as already demonstrated in the Java Enterprise space.”

IBM said, “IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.”

Among its list of comments criticizing the JCP votes, Apache said:

“This JSR's TCK license includes a "Field of Use" restriction that restricts commonplace and mundane use of independent implementations, a licensing element that not only is prohibited by the JSPA [Java Specification participation Agreement] but also has been unanimously rejected by the majority of the members of the JCP EC - including Oracle - on several occasions. We can only speculate why Oracle included such an element, but we believe that an open specification ecosystem must be independent of - and protected from - any entity's commercial interests.”

Red Hat concurred, saying, “We hope that all Specification Leads will…rank the viability of the Java Community higher than one individual member's abilities to monetize the platform.”

In its written comments accompanying its vote, the Eclipse Foundation said, “Eclipse is disappointed with the continuing issues around Java licensing. The unresolved TCK licensing issue with the Apache Software Foundation is a symptom of the fundamental problem with FOU restrictions on the Java platform. Our vote is based entirely on the premise that improvements and evolution are required if the Java platform is to remain viable.”

Next: A Grueling, Controversial Process >>