Friday 15 October 2010

Split JCP: a compromise proposal

I'd like to propose a compromise to the Executive Committee of the Java Community Process.

JCP compromise proposal

Firstly, a reminder. I do not speak on behalf of the Apache Software Foundation (or anybody else). This proposal is not endorsed by the ASF, nor do I have any indication that they would accept it. However, were Oracle and other members agree, I would recommend it to the ASF in my capacity as a member.

The compromise is around precisely what the JCP is, and what participants care about.

1) The JCP is a department of Oracle. It is not an independent body, and all legal agreements are between the member and Oracle (previously Sun). The dispute has caused grave mistrust in all other parties to the JCP, as Oracle has been shown to have all the power.

2) The JSRs, expert groups and development of specifications in Java EE, those built on Java ME and other non-core areas are functioning pretty well and still produce viable specifications. I call these the "ecosystem" specifications. Very simply, the JCP acts as neutral territory where multiple competing parties can lay down their weapons, talk, resolve conflict and produce results that benefit them all.

3) The JCP also hosts a few JSRs that are targetted at the very core of the platform. This includes the Java SE, ME and JVM specifications. I call these the "core" specifications. In each of these, Sun (now Oracle) has always and will always take the lead. They put in the vast majority of the money and act as the final decision maker. Oracle have made it clear that for these key areas they intend to retain that absolute power, while still listening to the community for advice and guidance.

4) The difference between the JSRs and approach in the core and those in the ecosytem is clear and absolute. Within the core everything is controlled and the community has only ever made requests of the company in power. Within the ecosystem neutrality and trust is vital, and here the community and vendors have done fantastic work.

5) The entire Apache Harmony dispute arises because the JCP places the management of the core and the ecosystem in one organisation and tries to apply the same rules. Both Sun and Oracle have refused Apache the TCK for Harmony because doing so crosses the red line between ecosystem and core. The problem is that the red line isn't explicit. (There are a whole heap of complexities and who said what to whom on top, but at its heart the red line is the issue.)

6) Therefore, I propose that the JCP should be divided in two.

Firstly, Oracle would publicly state that it is removing the core JSRs from the JCP and bring them in house. It would setup a separate formal body to provide advice and guidance on the core, but all participants would understand the limitations to their contributions. Clearly, the Java SE work would be focussed around OpenJDK as in Oracle's current plans. As part of this, there would be no vote on Java SE 7, as it would no longer be a JSR controlled by the JCP.

Secondly, Oracle would set the ecosystem part of the JCP free as a fully independent standards body organisation funded by all its members. The new organisation would be expected to produce clear membership rules including the ownership and management of IP.

A message for Oracle

Forcing though a Java SE 7 vote in the existing JCP doesn't solve your problems with the other vendors or the community. The real issue is the pretence that the JCP members have any control over the core specifications. Pretending that they do is a fraud, Apache Harmony exposed that red line and its time to break the JCP in two to solve it.

I strongly believe that you (Oracle) need the neutral ecosystem part of the JCP. It is in your interest to maintain and enhance that (as those ecosystem specifications are where you really get value). But an ecosystem standards body relies on trust with other vendors and community members. That trust is very low right now, and going to be non-existent if you force through the Java SE 7 vote. Just because you can win the vote doesn't mean that it is in your interests to do so. I'll also note that there is nothing stopping ecosystem participants creating their own standards body and excluding Oracle if they conclude that the loss of trust is fatal.

I believe that this compromise is very much in your (Oracle's) interests as it provides enough clean fresh air to get everything moving again while retaining control in the area you really care about.

A message for the Apache Software Foundation

This is a compromise and it means accepting that Apache Harmony cannot be an independent Java SE implementation. But pretending that there is any way for it ever to be one is at this point seems delusional. The gain on offer in the compromise should be clear - a clean functioning, independent body for Java ecosystem standards with sensible membership rules and IP management. This is a huge win compared to the current position.

I strongly believe that you (Apache) must not take that position that it requires Java SE to be an open specification in order to build useful code in the wider ecosystem. The C#/.NET platform is tightly controlled by a single vendor yet it can be used. The hardware isn't exactly open either. One might even argue that Linux is a similar very tightly controlled core with an open and thriving ecosystem on top. Its time to recognise that the core is frequently heavily controlled. And for good reason.

I believe that this compromise is very much in your (Apache's) interests as it finally clears up the rules and red lines in the world of Java.

A message for other EC members

I strongly believe that this compromise serves the needs of all parties better than being strong-armed. If you think it does, then ask Oracle and Apache to consider it before the Java SE 7 vote. After the vote will be too late.


The proposal is to split the JCP in two to finally be honest with everyone (vendors and community) as to the core that Oracle controls and the ecosystem standards body that everyone shares.

If you're a community member or vendor and like this compromise proposal please retweet or blog using #splitjcp.

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


  1. Geir Mangnusson Jr15 October 2010 at 03:03

    What a coincidence - I sent the same idea for discussion to the internal Apache member's list at 10:48 BST.

    I also discussed it w/ a few EC members earlier today as well.

    I think it's worth pondering, obviously.

  2. If Oracle doesn't honour Sun's original agreement with the ASF, how can they be trusted with whatever reorganisation they do with the JCP? Thats the fundamental flaw in your compromise.

  3. Stephen Colebourne15 October 2010 at 10:18

    Geir, its a concept that I've been trying to get listened to for some time (and have promoted privately for some considerable time). Recent discussions have simply reminded me to make it public. It is good to hear that it is "worth pondering".

    Niall, that depends on what motivations you ascribe to Oracle. I'm taking the view that Oracle wants to control the core, but is aware that they need a fair and balanced ecosystem too. Compromise requires stepping outside the comfort zone.

  4. Great to see a balanced proposal aimed at moving forward and leaving the past behind. It'd be interesting to see Oracle's reaction.

  5. Excellent post,
    below are my additions

    For now, An absolutely correct resolution as java(jvm) is proprietary unlike c language (so either we must bought it from oracle and do whatever we want otherwise oblige the terms of vender as always is the case.)

    Side by side, we need to form a new open CLR specification body like (OpenCL) and (OSGI),
    This body should produce a multi hardware platform, single but moduler CLR specification + specialized and general purpose languages on top of it.

    form a new proper implementation company with paid staff like any other regular IT product company.

    Funding/Sponsorship, We need to think who need these specifications and solutions open source and free...who is the user ?
    It is every industry/company who uses IT.
    Ultimately they will get the freedom of portability, longevity, cheaper and efficient solution, cloud like security so to reap the benefit they need to fund it.
    As some central body is present in every country for banking, funded by citizens tax through governments.
    IT companies need to discuss it with clients and set aside x percentage of every project to be contributed to specification body and implementation company.

    Being a programmer for me any solution proprietary or open source or free are alike as I get paid by time spent (hour) only not for java is free or c# is paid, i just assemble/maintain a solution and move on to another project. it is the client ultimately who needs delphi over cobol, java over c++, c# over vb and pays huge porting or legacy maintenance fees.
    If one language is inefficient, clients ends up paying more on hardware and electricity.
    If one language lacks some features it is client who ends up with semi solution or overpriced project.
    If one language lacks some liabrary it is client who ends up purchasing from third party if available.
    If one language is not portable, it is client who gets lock in.
    if one proprietary language dies (powerbuilder, delphi) it is client who drag the legacy.
    and so on...i am mere an solution assembler it is client who decides the budget, time, language, server, hardware.
    moral: it is between customers and their heavyweight venders (oracle weblogic, ibm websphere) or open source venders (struts, ant), I am to just build whatever my client asks (they have most of the things already fixed).
    that is it so until unless customers do not move to customers funded specs body and customers funded ASF the story remains the same in varying configutration.

  6. Some of these sentiments are what I was trying to point out on the jcp-general discussion group ( ).

    Basically why have implementations (RI and TCK) as part of a standard. No other standard body does so.

    I would go so far as to say have the spec (maybe including interface definitions as part of the spec) and maybe a test/verification spec. Decouple the specs from the implementations.

    I know this means more documentations and an extra step but this is a good common ground to develop the requirements of the JSR minus the implementation.

    You might still have to deal with patent concerns, but I think an algorithm included in a spec might still fall under a patentable realm.


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.