Tuesday, 7 June 2011

Java SE 7 passes in the zombie JCP

So in the end, there is a "Java SE 7". The vote at the JCP Executive Committee passed. But since I first started following this story back in 2009 its been a long road with a huge political fallout.

The Yes vote today happened because Oracle made a decision to kill Apache Harmony. A decision that was a continuation of Sun's policy, but one that Sun was not strong enough to make happen. Oracle's decision was to tell the JCP that it would proceed with version 7 no matter what the Executive Committe voted.

The cost of this decision was that Doug Lea, Apache and Tim Peierls left the Executive Committe. As such, I view the JCP as a zombie and under no circustances an Open Standards body, as promised in 1996.

You cannot claim to be an Open Standards body if you do not allow implementations of the specification.

So, this vote today is realy the end of a very long story - see below for the full history of blogs. As always in the JCP votes, the Yes/No vote is only half the story. The comments tell you the rest:

On 2011-05-31 VMWare voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-05-31 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-01 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-01 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-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 2011-06-02 RedHat voted Yes with the following comment:
Red Hat's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. Red Hat would prefer a licensing model that creates an open arena for everyone, including those not members of the JCP and removes any ability for one individual or vendor to exert undue control over a standard. We are an open source company and hence would like to see such a licensing model for JCP contributions. Note however, that this comment is not necessarily directed at the license terms for this JSR, but is a statement of Red Hat's preferred licensing model.
------------------------------------------------------------------------------
On 2011-06-02 SAP AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-02 Google Inc. voted No with the following comment:
While Google supports the technical content of this JSR, we are 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. Licenses containing such limitations do not meet the requirements of the JSPA, and violate the expectations of the Java community that JCP specs can be openly implemented."

The proposed license clearly violates this requirement (see Exhibit A, Section II). Oracle was duly reminded of this when JSR-336 was first proposed, but has done nothing to address the issue. It would be wrong to condone the inclusion of field-of-use restrictions in a TCK license, as this clearly violates the JSPA, by Oracle's own admission. Google does not want to slow the progress of this release, but we do believe it is critical that this issued be addressed, in order to comply with the JSPA and to preserve the openness of the Java platform.
------------------------------------------------------------------------------
On 2011-06-05 Keil, Werner voted Abstain with the following comment:
While I wish new and improved versions of Java to be released as soon as possible, given multiple delays in the past, the lack of transparency both in this Umbrella JSR and relevant components (especially Project Coin) fuel my decision to abstain here.

Not only have other EC members expressed their discomfort with this situation and confirmed some of these developments behind closed doors they demanded being opened, haven't been. The Spec Lead has also publicly admitted he wished, more of the SE-related activities were open and transparent than they were so far.

Given the efforts for more transparency by JSR 348 were just accepted by a larger majority than even this JSR or most others in SE/EE, I hope some more existing JSRs respect this and become more open especially if related projects even use names like "Open..."
------------------------------------------------------------------------------
On 2011-06-05 London Java Community voted Yes with the following comment:
The LJC votes Yes to the JSR for SE 7 based on its technical merit and our very strong desire to get Java moving again.

We note that the archives for some of the Expert Groups that comprise this JSR have not yet been made public, despite a promise from Oracle to do so. We do not feel that this is appropriate for a public and open standards body. In particular, Oracle's silence as to why the archives have not been made public is harmful to community participation, i.e. the community has no access to historical technical discussions, which are vital for participating in future Java language initiatives.

Going forward, we are unlikely to support any JSRs that do not meet minimum standards of transparency.
------------------------------------------------------------------------------
On 2011-06-06 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-06 Goldman Sachs & Co. voted Yes with the following comment:
Goldman Sachs votes Yes on JSR 336 based on its overall technical merit and our support for moving the platform forward

This umbrella JSR suffers from an overall lack of transparency compounded through inclusion of other JSR's as components which in turn are opaque. We clearly need to improve the transparency of the constituent parts and ensuing that the community has a clear understanding of what is coming. We are hopeful that JSR 348 (JCP.Next) starts to address these issues
------------------------------------------------------------------------------
On 2011-06-06 SouJava voted Yes with the following comment:
SouJava votes yes on this JSR based on its technical merits. Our members are satisfied with the evolution of the technology, but are unhappy with how the licensing terms in this proposal discriminates against open source implementations, and how this can negatively affect or influence other JSRs. We also have concerns about the lack of transparency of some of the JSRs involved in JSR 336, and how it has negatively impacted the Public Review process. We urge the Spec Lead to rectify this immediately, long before the Final Draft is presented.
------------------------------------------------------------------------------
On 2011-06-06 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-06-06 Fujitsu Limited voted Yes with the following comment:
Fujitsu's vote is based on the technical merits of this JSR, but not based on the licensing terms.

------------------------------------------------------------------------------

Considering this is a major release of Java, a platform used by more than 8 million developers, those comments are not a ringing endorsement.

Specifically, the comments note that Oracle's promises to have open and transparant JSRs have not been fulfilled.

More broken promise then. Why am I not surprised.

As I said, there used to be a Deal. Where the owner of Java makes a large investment and the community makes it relevant. By constantly thumbing its nose at the Java community, Oracle is harming its own interests. But I don't think they care anymore.

And yet, it could still be fixed - <tounge-in-cheek>Apache OpenJDK anyone</tounge-in-cheek>?

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


This is the history of my blogs on the topic. I've starred my favourite entries:
No more Java 7 * - March 2009 - the first article linking Java SE 7 and Apache Harmony
A question of IP - March 2009 - a decription of how IP works in the JCP
Sun, Apache & IP - in pictures! * - March 2009 - a pictorial view of how IP works in the JCP
Shedding new light on No Java SE 7 JSR * - March 2009 - the first analyis of the JCP Executive Committee meeting minutes
The ASF perspective - April 2009 - the first analysis of the Apache Software Foundation meeting minutes
The JCP doesn't exist * - April 2009 - showing how the JCP is a department, not an organization
The Oracle perspective - April 2009 - discussing what Oracle might do now they were taking over Sun
US DOJ investigation - June 2009 - pointing out that the DOJ could intervene
JSRs submitted over time * - October 2009 - graph of the submission of JSRs over time
Power corrupts. Absolute power corrupts absolutely. * - August 2010 - Oracle chose to sue Google and break the community
The end game - October 2010 - Oracle entices IBM from Harmony to OpenJDK
Does Oracle have enough votes - October 2010 - analysis of voting intentions in the first vote on Java SE 7
Pragmatism or bust * - October 2010 - voting Yes rewards the bully, but voting No would end the JCP
Split JCP proposal * - October 2010 - IMO, still the best approach for the future of the JCP
Stacking the JCP election - October 2010 - where I claimed Oracle was manipulating the JCP election
My election choices - October 2010 - my choices for the JCP Executive Committee election
Bablyon 5 & the Great War of Java * - October 2010 - a look at the big picture using Bablylon 5 as an analogy
Four viewpoints of War - October 2010 - analysis of the comments of four major players
JCP election result - November 2010 - summary of the JCP Executive Committee election
Premium JVM thoughts - November 2010 - a premium JVM scared people but proved to be a non event
ASF ready to leave the JCP - November 2010 - the ASF announces that the Java SE 7 vote could result in it leaving the JCP
Oracle replies to the ASF - November 2010 - I decode the Oracle press statement to mean the exact opposite of what it appears to say
Java SE 7 and 8 JSRs published * - November 2010 - detailed analysis of the licensing mess that Java SE works under
Devoxx whiteboard votes - November 2010 - developer votes referring to the issue
First Java SE 7/8 votes pass - December 2010 - brief analysis of the voting, noting Intel's change of view and representative
Is the JCP dead * - December 2010 - questions the viability of the JCP once Doug, Tim and Apache left
The Deal * - December 2010 - my take of the deal between Sun and the community that Oracle doesn't understand
What about JSR-310 - December 2010 - my choice to continue JSR-310, using the JCP as a tool rather than a standards body
JCP Bonn meeting - June 2011 - notes on the decisive JCP meeting in October 2010

15 comments:

  1. As an active Java developer for whom Java has been more than a language, it feels painful the way Oracle has started tightening its control over the domain, much in the walled-garden approach of Apple.

    But is there something we (community developers) can do other than sit quietly and watch doom? :(

    ReplyDelete
  2. Jaap Beetstra7 June 2011 13:13

    Thanks for posting these updates about the process all this time. I am saddened by the results.

    ReplyDelete
  3. @Sandeep in particular.

    Licensing and transparency issues will be at the for of the JCP.next discussion. JSR 348 will address transparency and a (hopefully near) future JSR will start the discussion on the JSPA.

    We disagree that the JCP is "zombie" and irrelevant. We don't think it is, and this is why we stood for the JCP EC, so that we could effect change from the inside working with Oracle et al.

    What can you do? Join SouJava or the LJC (or one of the other JCP EC members whose statements you agree with) and help them promote change!

    Martijn (on behalf of the LJC)

    ReplyDelete
  4. Honestly I think it's just as bad that these JCP members vote yes but comment like they give a damn. The reality is they want to stay in Oracle's good graces so it doesn't affect their bottom line. To me it is sad companies like Redhat didn't back up ASF with action instead of words.

    ReplyDelete
  5. Almost year ago the was some plans to do Lava - OpenJDK fork in order to get JDK TCK
    and make Lava TCK compatible with Java TCK but w/o stupid FOU restriction.
    What do you know or think? Is there any hope?

    ReplyDelete
  6. You can't effect control from inside when Oracle have already said they don't care what the JCP says. Nieve.

    ReplyDelete
  7. Stephen Colebourne8 June 2011 12:59

    @Sandeep, @Olexandr, IMO any project trying to fork Java or write an alternate version is likely to be disappointed. Oracle has made it pretty clear that they won't tolerate any other kind of Java (and Google is their target on this). Its time for Java developers to recognise that they live at the whim of Oracle and the "Java trap" is absolute.

    @Martijn, I widh the LJC, SouJava and others well on the JCP. But unless you can get the JCP split into two parts, one with specs that can be implemented and one with specs that can't then frankly the JCP isn't of much interest to me. ( (ie. rewrite the JSPA legal agreement so it isn't being broken by Oracle). Bear in mind that right now even Oracle just sees it as a tool rather than anything to pay attention to, see your Java SE 7 comments.

    ReplyDelete
  8. @Stephen:
    Oracle did some good thinks (java is moving for example). So maybe, just maybe, JCP.next really gets something going? They screwed OpenOffice up, maybe they learned...

    ReplyDelete
  9. No offense, but: what drives you to write all these blog posts? Oracle 's finally moving Java forward again, yet some people can't stop complaining about this TCK issue. What was the added value of Apache Harmony anyway?
    The problem with Google is that they 're breaking the "write once, run anywhere" Java slogan.
    Oracle brought IBM & Apple to the OpenJDK & is moving Java forward on all fronts. Maybe I 'm naive, but Java 's future seems bright to me.

    ReplyDelete
  10. Stephen Colebourne9 June 2011 09:31

    @Matthias, Yes Oracle is investing lots in Java, and thats a good thing. JCP.next has a few tweaks, nothing important.

    @Anthony, I became the unoffical documenter of this sad story, so I have to complete the documentation. Its still a real issue, because its at the heart of the Oracle Google lawsuit. Oh, and I take it you'd be happy to only have Glassfish in Java EE, and no Geronimo, JBoss, Websphere...? The point of the JCP is to be a standards body allowing multiple competing implementations!

    ReplyDelete
  11. Stephen & Matthias - I appreciate that YMMV, but the LJC strongly believes that JCP.next (as represented by JSR 348) is actually a significant and important JSR in its own right as well as being a positive start. The JCP (and some JSRs) has lacked openness and transparency in the past, which has certainly hindered many standardisation efforts.

    In particular, the LJC has noticed that the 'Java developer on the street' knows very little about the JCP or JSRs (if they've heard of them at all!). JSR 348 is an important base to start from so that Java developers can get directly involved and help shape really great standards.

    I'll note that Oracle did submit this JSR, a welcome and positive move from them :)

    JSR 348 is being conducted transparently, in the open.

    It is our intention to ensure that all JSRs which are created during our term are done in an as open a manner as possible. We welcome your feedback and input into this process - especially if it takes the form of constructive criticism or suggestions about where best to spend our attention.

    Cheers,
    Martijn & Ben (on behalf of LJC JCP committee)

    ReplyDelete
  12. Stephen Souness10 June 2011 09:54

    As a member of the LJC (though not on any committee) I would prefer it if Martijn et al qualified their comments on public forums such as this blog.

    Statements beginning with, "the LJC strongly believes" imply that some sort of survey has been taken to establish popular opinion.

    I like seeing statements of facts and really appreciate the transparency that this blog brings to the history of the JCP.

    Of course this is just my opinion.

    :)

    ReplyDelete
  13. Martijn Verburg10 June 2011 20:40

    Hi Stephen S,

    You're quite right, I didn't qualify that statement correctly! I'm new at this and am still very much learning how to balance and phrase things accurately.

    Please once more accept my aplogies.

    Cheers,
    Martijn

    ReplyDelete
  14. Hi Stephen,

    Thanks for reminding us of the balance that we need to strike. Representing such a diverse group as the LJC is a real challenge - I would say more so than representing a corporate entity - because we have to represent a rough consensus of the view of our 2000ish members and don't have a corporate hierarchy to dictate our position for us.

    Getting a view on that many different perspectives is tricky - and that's why the members of the JCP committee need to spend a lot of time talking to people to find out their views and then work out what a representative and reasonable synthesis of them should be. That's not perfect as a sampling technique - but it's what we have in place right now.

    We're always interested in our members views, and suggestions for how we can improve and better represent our community. This is a learning exercise for us too, and we certainly don't claim to have all the answers!

    This is also a great reminder - I have half a blogpost about how we're working within the JCP - I must find some time over this weekend to dust it off and get it out there.

    To return to your original point: Given that as the LJC we need to be a unified voice in the JCP Exec Committee - how would you like to see us express our understanding of the community's view in forums such as this blog? What are we doing right, and what can we do better at?

    Thanks,

    Ben

    ReplyDelete
  15. I have no problem at all with the current behavior of Oracle. Rather, I'm pleased that Apple and IBM has jumped on the train. And I won't shed a tear on the fact that Apache is a dead project now.

    Apache followed a very dangerous path when they followed IBM in it's try to overcome Java leadership. Maybe Google thought that Harmony would be the de facto standard when they used it for Android.

    It's seems that people (I'm not speaking specifically about pthis blog) are very happy about Google's dubious way of doing with Android, or Microsoft way of doing with .NET, but are never happy with how Sun, then Oracle did with Java.

    Please remind that Sun disappeared because they could not make enough money on their business, including Java, while others (say IBM, Google) made a LOT of money on what Sun invented while giving nothing in return

    So I have no problem at all with the attitude of Oracle. The state of development of Java is much much more open than how Android is managed by Google, mostly under closed doors. Go to OpenJDK site, and see how development is made in the open. ON tnhe other hand, I would really want to know wnhat's going on with Harmony now, on about how Google is doing with their own implementation for >Android, because it's VERY opaque.

    ReplyDelete