eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.”
JCP Gives Java 7, 8 Roadmaps Greenlight Under Protest
title=A Grueling, Controversial Process}
Eclipse’s executive director, Mike Milinkovich, also told eWEEK, “This process has been grueling and highly controversial. We are happy to see that it has reached the conclusion that the Eclipse Foundation has been supporting for some time. Although the vote was not a consensus, it was strongly in favor of moving the Java platform forward. A movement we believe is critical to its future success.”
Perhaps the most telling comments come from Credit Suisse, which is more of an enterprise user member of the executive committee with no skin in the game as a vendor of Java technology. Although qualifying that its vote was purely on the technical content of the JSR, Credit Suisse said:
“We strongly demand open standards and an active community around Java as we selected Java SE & EE as primary pillars for our application development (as many others in the industry do). The current battle around licensing term, however, reveals that Java never actually was an open standard. FOU restrictions clearly discriminate open source implementations and prevent competition, and with that, innovation in that space. While Java had a considerable head start, it lost a lot of momentum over the last years. Fragmentation (or a fork) of the language and its platforms are clearly not desired. But today, customers are already facing competing models for developing enterprise applications (e.g., Spring, OSGi, Java EE). The main problem, in our view, is the lack of modularization, clear delineation of Java IPs owned by Oracle and truly open standard extensions, and the ignorance of developments outside of the JCP (even though OSGi has a JCP blessing). The OpenJDK framework is not sufficient for all aspects of the language. Java must be kept interesting for researchers and universities: researchers not only contribute to the standards (e.g., Doug Lea for concurrency or Michael Ernst for type annotations) but also decide on the languages (and paradigms) that are taught at universities — and this in the end determines the knowledge and mindset we acquire with our software engineers. While we recognize Oracle’s intellectual properties around Java, we strongly encourage Oracle to re-think its current position around licensing terms. We strongly support open source as a licensing model for contributions in the JCP.”
Added Werner Keil on the modularity issue, “I share discomfort with less talked about, but nevertheless tedious problems like the lack of modularity in SE7 and its effect on dependent JSRs like EE.”
Meanwhile, Peierls’ expressed frustration that no matter what the outcome of the JCP vote would have been, “one can only conclude that the SE/EE EC is never going to be more than a rubber stamp for Oracle.”
The issue of the monetization of Java — which Java creator Sun Microsystems was criticized as not getting – is central to Oracle. As Peierls said:
“The big boys want big apparent forward motion because it means more stuff to sell, more contracts and control. As a result, we are whipped to a frenzy with messages (both subliminal and explicit) that Java is falling behind, losing mind-share, being lapped by C#, anything to sell the idea that more is desperately needed, when in fact most folks could make do with a lot less.”
Indeed, Peierls says the rush to move Java forward could be nothing more than a smokescreen. “I’m coming to believe something heretical, that it actually is not all that crucial for Java to move forward,” he said, “at least not to the constituency I felt that I represented on the EC, the tens of thousands of Java developers who don’t work for a big company with an Oracle contract.”
Meanwhile, in a press release on the vote, Oracle said with the JCP approval, the Java standard will progress through the JCP while the open source reference implementation will be delivered through the OpenJDK project. The plan calls for standardization of these technologies in Java SE 7 within 2011, with Java SE 8 following in 2012. Java SE 7 includes language changes for improved developer productivity, dynamically typed language support, and performance improvements. Java SE 8 includes technologies in support of Java modularization and language enhancements for advanced multicore support.
“Oracle appreciates the efforts of the Executive Committee and the entire Java community in helping to make this important step forward for the Java Platform,” said Hasan Rizvi, senior vice president of Oracle Fusion Middleware and Java, in a statement. “Oracle outlined a specific roadmap for Java SE 7 and Java SE 8 at JavaOne in September. We are pleased that the roadmap was ratified by the JCP Executive Committee. We see it as the next step in our delivering significant updates to the Java Platform and Language Specification.”
Also in a statement, Adam Messinger, vice president, Oracle Fusion Middleware, said, “The JCP Executive Committee approval of the Java SE 7, Java SE 8, and component JSRs follows Oracle’s recent announcements surrounding OpenJDK momentum with IBM and Apple participation. Together, these developments demonstrate a renewed energy behind Java and strengthen its future as the language and platform of choice.”
For its part, Oracle listed several facts and figures on the usage of Java, including that more than 1.1 billion desktops run Java, there are 930 million Java Runtime Environment downloads each year, 3 billion mobile phones run Java, 31 times more Java phones ship every year than Apple and Android combined, 100 percent of all Blu-ray players run Java, and 1.4 billion Java Cards are manufactured each year.