Tuesday 7 December 2010

Java SE 7/8 passed

So, the Java SE 7 and 8 votes passed.

Java SE 7 passed by 12 votes to 3 (Apache, Google and Tim Peierls voting against).

Java SE 8 passed by 12 votes to 3 (Apache, Google and Tim Peierls voting against).

Project Coin passed by 13 votes to 1 with 1 abstention (Apache voting against and Tim Peierls abstaining).

Project Lambda passed by 13 votes to 1 with 1 abstention (Apache voting against and Tim Peierls abstaining).

But it looks like many of the voters were unhappy.

Java SE 7 vote results

When voting for a JSR there is the opportunity to leave comments. These often indicate the true feelings of voters more than the actual Yes or No. Here are the actual vote comments for Java SE 7 (the Java SE 8 comments are similar but with reference to OSGi):

On 2010-12-03 Peierls, Tim voted No with the following comment:
Changing my vote from "Abstain" to "No" to register my extreme disappointment with Oracle's failure to address EC questions about the licensing terms of this JSR.
On 2010-11-17 Google Inc. voted No with the following comment:
While we support the technical content of this JSR, Google is voting no because of its licensing terms. As per the JCP resolutions of 9/25/2007 and 4/7/2009, "TCK licenses must not be used to discriminate against or restrict compatible implementations of Java specifications by including field-of-use restrictions on the tested implementations or otherwise. Licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates, and violate the expectations of the Java community that JCP specs can be openly implemented." Most EC members, including Oracle, voted for both of these resolutions. But the proposed license clearly violates them in Exhibit A, Section II.

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.
On 2010-11-17 Oracle voted Yes with no comment.
On 2010-11-29 SAP AG voted Yes with the following comment:
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.
On 2010-11-30 Hewlett-Packard voted Yes with no comment.
On 2010-12-02 IBM voted Yes with the following comment:
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
On 2010-11-30 Ericsson AB voted Yes with no comment.
On 2010-12-01 Apache Software Foundation voted No with the following comment:
The Apache Software Foundation must vote no on this JSR. While we support the technical contents of the JSR, and earnestly support the need for the Java platform to move forward, we cannot in good conscience vote for this JSR because :

a) 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 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.

b) On process grounds, this JSR is in conflict with it's own TCK license. The JSR explicitly states that Java SE is targeted for, among others, embedded deployments. Yet the TCK license specifically prohibits such usages (for example, netbooks) of tested independent implementations. We find this to be a misleading legal trap for potential implementers, and believe that any independent implementation that passes the TCK should be able to be used and distributed under whatever terms deemed fit by the implementer.

c) The spec lead has ignored repeated requests from multiple EC members for and explanation of both a) and b)

d) The spec lead - Oracle - is in breach of their obligations under the JSPA by continuing to provide a TCK license for Apache Harmony under terms that allow Apache to distribute its independent implementation under terms of its choice. We do not believe that anyone that willfully fails to meet their contractual obligations under the JSPA should be allowed to participate as a member in good stating in the JCP. The rules apply to everyone.

While we understand that it's Oracle's stated intent to move forward irrespective of the EC's decision, we urge Oracle to fix the above-mentioned issues, and continue to work with the members of the JCP within the structure of the JCP to keep Java a vital and viable platform.
On 2010-12-02 Eclipse Foundation, Inc voted Yes with the following comment:
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. In addition, we remain concerned that the future of Java modularity may fail to adequately reflect the requirements of the existing OSGi community and ecosystem. Future votes on these JSRs will reflect this concern.
On 2010-12-02 Fujitsu Limited voted Yes with no comment.
On 2010-12-04 RedHat voted Yes with the following comment:
Red Hat's vote is based solely on the technical merits of the JSR. We believe that this JSR is important for the industry at large and that further delays risk fracturing the Java landscape further. However, we are extremely disappointed with the license terms and that a more open license has not been adopted by the Specification Lead. We continue to believe that the TCK should contain no "field of use restrictions", as originally raised by Apache with regard to another JSR during the development of EE6 (i.e. the SE TCK licensing). As a result, this approach risks limiting adoption of this and subsequent JSRs by a wider audience and the fracturing that we mentioned earlier could still occur. We hope that all Specification Leads will take this into account in the future and rank the viability of the Java Community higher than one individual member's abilities to monetise the platform.
On 2010-12-05 VMWare voted Yes with no comment.
On 2010-12-06 Keil, Werner voted Yes with the following comment:
While I'm equally dissapointed with the ongoing license dispute and the effect this and other issues had on the actual content and scope of Java 7 (I am not the only one who feels this is technically hardly worthy of a version major compared to especially Java 5) I believe, it is a necessary and long overdue step towards the future of Java. 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.
On 2010-12-06 Intel Corp. voted Yes with no comment.
On 2010-12-06 Credit Suisse voted Yes with the following comment:
Credit Suisse's vote is purely on the technical content. 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.


There is a lot in those comments to understand, and I can't cover it all now.

I do note Time Peierls decision (as an individual) to change his vote from "Abstain" to "No" and the reason given. Clearly, Oracle were asked to explain their licensing terms and how they square with the JSPA, and with the JSR text itself, and have failed to do so. My interpretation is that Oracle no longer felt the need to justify its actions.

I also castigate Hewlett-Packard, Ericsson AB, Fujitsu, VMWare (SpringSource) and Intel for not even having the courage to justify their actions (which are in direct opposition to previous votes). I will note that Intel has previously been a strong Apache supporter. However, I understand that the Intel representative on the JCP was changed a few months back, prior to the vote (no public source to confirm this as far as I know Update: the executive committee members list has been updated to show the change, which happened since July).

I am disappointed in all the "Yes" voters. Clearly Oracle intended to move Java SE 7 forward irrespective of the vote here. Thus voting "No" would have had no adverse consequences on the forward momentum and technical progress of Java. Since the main role of the Executive Committee, distinct from Expert Groups, is to consider the business implications it is clear that each company that voted "Yes" has given tacit approval to the business practices of Oracle. I suspect that they will come to regret that decision. Give a bully an inch and they will take a mile.


Today, Oracle won its battle in the JCP. But it was a stupid battle to have. Submitting a JSR whose licensing terms are in conflict with the JSR itself and with the JSPA was simply unnecessary. Voting "Yes" to it was simply cowardly.

The huge irony is that Oracle claims to support Java because all of its money making systems are written in Java, thus it is in its own interests to keep Java vibrant. Yet the strong-arm actions here simply push people away and harm that vibrancy. Go figure.

We should expect the response from the Apache Software Foundation soon.

Stephen Colebourne
Apache Software Foundation member, speaking personally
Oracle Java Champion, speaking personally
Not a committer on Harmony or OpenJDK


  1. You all coward sheep !

    My remark is purely technical.

  2. Personally, I think it's a good thing JDK7 finally gets on its way.

    But whether it's worth JCP (hence Java also) being discredited once more ... What good are voting members who think one way but vote the other for the credibility of their organization ?


  3. Committee work is too slow.

    Go Oracle!

  4. You say "My interpretation is that Oracle no longer felt the need to justify its actions."

    Does anyone recall a time when Oracle felt they /did/ need to justify their actions?

  5. Let me repost the same comment I have posted on Bob Lee's blog post regarding the same issue:
    I don't think the changes to license agreement would have any practical difference from what they were under Sun's leadership. Sun didn't remove the restrictions on the TCK and showed no intention of changing their mind. The new license wording just clarifies what it is that they are prohibiting (basically a third-party open-source implementation of the Java platform).
    So this is exactly as it was before, only specified more clearly. So, yes, the Java SE specification is not entirely open, and it never has been.
    Somehow, this rebellion broke out only after Sun's acquisition. It seems to me that the reason is that Oracle just seems an annoying organisation (which it definitely is), and Larry Ellison seems like an annoying guy (which he probably is). Also, Oracle is just too powerful. IBM and Google like the Java leader to be weak. Sun was. Oracle isn't. That's the only reason this is all happening now.
    I don't think this affects the Java user community that much. We have the OpenJDK, and commodity Java products have never made much use of Harmony. This only affects huge companies that want to distribute their own Java platform without licensing it from Oracle.
    Well, IBM, HP, Apple and some other smaller companies have licensed their Java implementation. Only one major company hasn't, and that's Google.
    So while I sympathize with the desire to see Java truly open, it never has been, and the current struggle is simply a corporate struggle between two giants (now that IBM allied with Oracle) - Oracle and Google.
    Google simply, cleverly enough, conduct their corporate battles by proxy, this time using the Java community.
    This is all fair, but I hope Google would spare us the hypocritical morality talk. If they continue down this path, soon they would be as annoying as Oracle, or even, god forbid, as annoying and as hypocritical as Apple.

  6. Note that this rebellion did not begin with Oracle's acquisition.

    Apache has been leading the fight against Sun for a long time (note 'Open letter' of April 10/2007 - http://www.apache.org/jcp/sunopenletter.html ). All other members (including Oracle) expressed displeasure with Sun's behavior around FOU. Part of the reason it has taken so long for Java 7/8 JSRs was the fear of the JCP vetoing them.

    The battle did go into a holding pattern during the protracted take-over and there was hope that things would change under Oracle. But they did not (hence Doug Lea leaving etc).

  7. @MJF
    True enough, only back then, Apache's protest went almost unnoticed, except by some open-source enthusiasts. This time, this whole business is raising a much bigger stink, and is covered even by the less involved media. The reason for that is not Java's compliance with open-source ideals, which, IMO, is quite reasonable, but rather Google's stoking the flames, and using Apache to further its (i.e. Google's) own corporate interests.

  8. Tim Peierls has resigned from the JCP EC ( http://tembrel.blogspot.com/2010/12/resigned-from-ec.html ).

    "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. "
    "Add to that Oracle's expressed intent to proceed with the SE7/8 JSRs whatever the outcome of the vote, and one can only conclude that the SE/EE EC is never going to be more than a rubber stamp for Oracle. (The belligerent tone with which this message was delivered does not come across in the public minutes, but it was loud and clear over my phone connection.)"

  9. "Rubber stamp" was pretty much the term that occurred to me as well. It's a shame, and a sham. If everyone had voted against these JSRs, it would probably have meant the end of the JCP process. I suppose just as well, since it appears to be meaningless. It's either Larry's way or the highway, as we have known for a long time now.

  10. @pron
    There definitely has been a substantial increase in visibly driven by some of Oracle's actions (suing Google, convincing IBM to 'abandon' Harmony, etc). There was also a loss of many people's (e.g. Doug Lea) last, best hope (that Sun's purchaser would drive the 'right' thing happening).

    My point is the licensing/FOU has been clogging up the JCP for much longer. Sun wanted Java 7 a long, long time ago. A Java 7 JSR was delayed by Sun's fear of if failing on this point. This also resulted in the opportunistic shift of Java standards evolution from JCP to openJDK which perhaps is for the best.

  11. I hope Oracle runs with the ball. Clearly they are still going to get input from the community and can implement and innovate in Java more quicker now.

    Everything is all speculation at this point on how it all plays out.


Please be aware that by commenting you provide consent to associate your selected profile with your comment. Long comments or those with excessive links may be deleted by Blogger (not me!). All spam will be deleted.