August 2nd, 2011 by Dan Allen

Open Letter to the JCP Executive Committee calling for JCP reform

Seizing the opportunity of a new Executive Committee (EC) under a new regime, I’d like to issue a call for reform of the Java Community Process (JCP) to allow it to produce more iterative and timely technology and live up to it’s name as a “community process”, rather than acting as the “corporate process” many believe it is today [1].

Goals and current problems

The goal and of this call to action parallels a statement made by Mark Little, CTO of JBoss and member of the EC, in response to questions for the 2010 EC candidates [2].
We believe that the EC still has an important role to play in the future of Java, and working within the EC is the best place to push for change and improvements. Java is certainly more “open” now than it was a decade ago, but it’s not as open as […] other standards bodies [OMG, OASIS, W3C and IETF]. We would like to see that change.
Indeed, the central problem with the current JCP is lack of transparency and openness. Although the JCP defines itself as “the open, participative process to develop and revise the Java technology specifications, reference implementations and test suites”, it’s not very open nor participative in practice. The community is almost entirely excluded when developing so called “open standards”. The root cause of this problem is that the Expert Group (EG) mailinglists are not open to the public (save a few exceptions, notably JSR-303 and JSR-311). The mailinglists are where the bulk of the technology design takes place. The private mailinglists don’t merely close the doors to the general public. EG members from one JSR can’t even read the correspondence of another JSR. Feedback is one directional, from community to EG. All the general public can see are the drafts of the JSRs. They don’t know how the EG arrived at that draft, meaning they aren’t able to study the discussions that went into it. The EG may reciprocate by publishing another specification draft, with or without the feedback incorporated. While companies and major Java leaders are involved in the JCP, individuals from the Java community have to really fight to be included or provide feedback. Let us not forget the significance of their participation, as Mark Little points out.
A strong JCP and a strong EC should be to the benefit of the entire Java community and not just to a select few.
The JCP also fails to respect the nature of software development. Instead of following an iterative process, JSRs target big-bang releases that have no clear continuum to the next generation. These major shifts in the platform make it increasingly harder for consumers to carry out migrations. Smaller releases would be easier to adopt. There are also huge lapses between releases, which is time for the technology to fall out of date. How can we expect to define a unified and consistent platform that integrates well if the technologies bundled are created in different campuses at different times? The decisions that occur behind close doors effectively turn off would be participants and consumers. The community becomes frustrated because they don’t know what’s going on. It’s true that progress can emerge even from even a crippled process. There’s no doubt that Java EE has been experiencing a revival since the release of Java EE 6, but with no clear target for EE 7, how long can the honeymoon last? Bill Burke cites how a small company like Red Hat has been able to make a big impact on the JCP standards [3]. He provides this evidence to make the point that the JCP is salvageable. Great, so let’s salvage it and get it moving again.

The call for reform

I propose that the JCP redefine itself as:
“An open, community-oriented standards organization that produces standard technical specifications for Java technology in order to keep it competitive and to bring value and choice to businesses worldwide. These goals are achieved by honoring the nature of software development, which means fostering a collaborative, evolutionary process where change of all types (addition, revision and deprecation) is inevitable and standards are snapshots in a timeline along that evolution.Standards produced by this process are published under and open, non-clickthrough license, which applies to the specification documents, the APIs, the reference implementations (RIs) and the compatibility test suites (TCKs). A fair voting system is used to maintain a balance of power and there is complete openness of process and membership.The goal of this organization, above all else, is to produce timely, iterative, high-quality standards, which means never standing in the way of progress nor precluding proposals or ideas that may lead to a better way forward.”
To make it very clear what changes we are calling for, we provide specific points, ranging from “must have” to “nice to have”.

Must haves:

  • Specifications must be published under and open, non-clickthrough license, which covers the specification documents, the APIs, the reference implementations and the compatibility test suites
  • Specifications should be free to use and implement (no TCK fees)
  • Specifications must provide a non-clickthrough specification document, stored in an open VCS system and easily viewable online by anyone (a nightly build of the spec would be sufficient of the document is created by for-pay software)
  • Specifications should be required to publish API binaries, sources, and JavaDocs to Maven Central
  • Specifications must have public issue trackers, open source TCKs and public mailinglists for all JSRs, and require information about these resources to be public and easy to find
  • Expert Groups (EGs) should not be automatically disband after a final release of a spec (maintenance releases are an extremely important part of a JSRs evolution)
  • Maintenance releases should be easier to initiate (and get approved); the software process should be iterative
  • Names of individual representatives, and the company they represent, should be listed on the specification page; it should be clear who the representatives are
  • There should be an official process for deprecating or removing a technology; old technologies currently die a slow unused death, dragging the platform down, and leaving complexity in its wake as vendors are required to pass the TCKs; let’s not hide behind the term “pruning”
  • All specification communication must be considered public, and must unless initiated privately by a member of the community, be held on said platform.

For accessibility:

  • Specification documents should be made available in HTML format for easy web access; PDFs should merely one viewing option, not the only one
  • Specifications should provide end-user, user-case driven documentation for a technology (for instance like the first half of the Weld reference guide and the Java EE tutorial)
  • Decent and familiar social business software should be used for to make it truly a community ( is extremely difficult to use and poorly organized)
  • should host all the specification artifacts (specification document, API, reference implementation and TCK) (there is currently too much burden on developer to find them)
  • Specification artifacts should require no more than two clicks to begin said download, with no login required

Nice to have:

  • Periodic EC meetings should be open to the public
  • Platform releases (i.e., Java EE) should occur at regular, scheduled intervals, every 6 months or so, with clear paths for ratification and deprecation of JSRs.
  • The JCP should be an independent organization, similar in structure to the Eclipse foundation; it should be run and funded by donations/investments rather than petty membership fees
  • JSRs must be allowed to compete with each other, or standards evolution merely excludes and fragments participation within the Java community (for instance, one view technology is not sufficient)

Support and endorsement

The evidence of a general call for JCP reform is widespread. Earlier this year, Mark Little, Red Hat’s representative on the EC, called for a more open process, with everyone acting as peers. [4] He reinforced those statements in his follow-up to questions posed to the EC candidates. [2] IBM states on their standards page that they will “begin or end participation in standards bodies based on the quality and openness of their processes, membership rules, and intellectual property policies.” [5] Bob Sutor has said that IBM expects to see “long needed reforms in the JCP […] to make it more democratic, transparent, and open.” [6] In an open letter from the CTO of SAP, Vishal Sikka, he calls for more openness in the JCP, saying “To ensure the continued role of Java in driving economic growth, we believe it is essential to transition the stewardship of the language and platform into an authentically open body that is not dominated by an individual corporation.” [7] Darryl K. Taft published an editorial in eWeek outlining 15 guidelines for making Java better, one of which included setting the JCP free. [8] Finally, Doug Lea made a firm statement a few weeks ago that the JCP is no longer a credible standards organization [9]. There are numerous other public statements on the web of calls for JCP reform.


I’m calling for reform in the JCP. I want the JCP to be accountable to its namesake, a “community process.” The fact that the JCP claims to be open but does not uphold this promise tarnishes it and causes people to lose trust. It’s a tragedy that the technology is way ahead of the process. But hope is not lost. A few fundamental changes would drastically improve the effectiveness and credibility of the JCP. As Mark Little has said, “we would like to see the JCP continue to evolve and address those issues which we all know tarnish it.” I hope that the new EC is brave enough to rise to this challenge. Signed, Dan Allen Lincoln Baxter, III Add your signature to the corresponding entry on ‘Petition Online’ to join the call.



Posted in OpenSource


  1. Hi Lincoln & Dan. A couple of short comments with the usual IANAL and “I’m speaking for myself, not my employer”

    * Some things you are asking already exist. For example, open mailing lists are totally OK with the current JCP process – although I know the infrastructure support for some of this is not where it should be.

    As another example, there is a process to remove specifications from the platform.

    * Some things you are asking are quite complicated. For example (and IANAL) click-throughs on specifications are required to enforce licenses, etc. It might be more productive to spell out the intrinsic requirements rather than the derivative ones.

    And thanks for the post!

    1. Dan Allen says:


      Thanks for your comments. I’m glad that you have taken notice of this call to action and are willing to provide your feedback.

      I think you are missing the emphasis of our call for open mailinglists. I recognize that open mailinglists are permitted. JSR-311 set the precedent by exercising that freedom ( JSR-314 also attempted to go this route, though it ran into the infrastructure support problems that you mention.

      Our point is that open mailinglists should be required. You cannot have a community process and hide all the major design discussions. I recognize that there is still a need for a private list to discuss legal and IP topics, and likely private e-mails will be exchanged as well. But all core design discussions should be, and need to be, public.

      Claiming that our request to remove click-throughs (clickwraps) on the license is complicated is contrived.

      Open Source licenses do not require a “click-through” to establish agreement to the terms. That’s one of the key reasons for having such standard licenses. They are agreed to based on the act of using the software (agreement is implied, in other words, generally enforceable). They do not require forced and obtrusive “virtual” handshakes that assume the shape of a Accept button. (citation:

      I hope that you understand that I am fighting for the platform, not against it. I want to move the platform forward. I want it to appeal to the extremely broad Java community so they get behind it in unison again. The best way we can accomplish that is by permitting the community to participate without barriers while protecting the platform under a unified cause of openness. Let us not fear freedom.

  2. Lincoln, as a JCP member (represent ASF for JSR-299), I am %100 same with your comments.

  3. Likewise, the Apache Software Foundation has long had an open letter to Sun (now Oracle) about a very related subject: ensuring that JCP-generated specs can be implemented under open source licenses.

    In the recent EC election, the ASF was ratified by the vast majority of EC voters, which we’re very happy about.

    1. Dan Allen says:


      Yes, I’m familiar with ASF’s open letter to Sun. That’s one of the reasons I am so proud of the fact that the JSR-299 and JSR-303 TCK are licensed under the ASLv2. In one sense, that is how Red Hat showed support for this letter.

      I believe that Apache’s letter and our own challenge the JCP on the same point, which I’ll quote from the former:

      “In an open ecosystem, it must be the case that the necessary IP to implement a specification can be secured independently from the specific commercial interests of any one actor in the ecosystem…Your restrictions violate the basic protections of the JCP…this failure to comply with your contractual obligations poses serious risk to the credibility of the JCP as an open standards organization, and the reputation of Java itself as an open technology.”

      It’s all about the fact that the JCP is not following through on it’s promises, and that enforcement of violations are not being pursued. Doug Lea made the very same point in his open letter.

      The JCP should live up to its namesake as a community process and should commit fully to the openness that it promises.

  4. JDOM (JSR 102) was the first EG that I know that was fully transparent; that was a long time ago. The biggest issue with transparency is for the EG members to agree to it beforehand. IANAL but in the old/current JSPA the IP does not transfer to the Spec until the point when it is approved by the EC and goes final, so public discussions w/o JSPA are complicated from an IP perspective.

    The situation might be easier for a vendor, like Red Hat, that generates revenue from selling support licenses, but that is more complicated for vendors that sell runtime licenses. And the less commoditized the market, the more tricky the IP is.

    Re: the value of click-through licenses – I’ve heard different arguments from different lawyers. It really does not matter what I think; it matters what the relevant lawyer thinks.

  5. Dan Allen says:

    Thanks for the clarification about the first fully transparent specification, JDOM (JSR-102).

    The need for that clarification raises another point, though. It’s extremely difficult to figure out where the important resources (mailinglists, issue trackers, etc) are for a given specification (or the entire catalog). The JCP PMO went and added a link on every specification page (even inactive ones) to a forum. That only further confused the situation. Most of the linked forums are empty (obviously for the inactive specifications) and few EG members even know about them.

    Having established that JSR-311 has an open mailinglist, you wouldn’t know it from the JSR page:

    I really look forward to getting this sorted out.

  6. +10 on clarifying the situations!

    And, BTW, the GlassFish project has used transparency very effectively over the years and I am a big fan of it; I don’t know if JBoss has improved things, but at some point, I could say that GF was more transparent than JBoss .

    My reaction is on the “must be transparent” part. I (speaking personally, not as an oracle employee!!) would react differently to a “default is transparent” proposal.

    re: JDOM – yes, that was Jason’s baby. He did a good job there, although keeping the whole thing moving was a lot of work.

  7. Gero Seber says:

    Reforming the JCP? You are wasting your time.

    The JCP is exactly how its puppet masters Sun/Oracle want and wanted it to be. The community was excluded right from the beginning. And this was no accident. This was fully intentional, and was and is defended with teeth and claws by those paying for the JCP to have it their way.

    The JCP produces largely irrelevant specifications. Specifications that never get finished. Specifications that completely miss the mark, designed by committee and academics with too much time on their hands, with the most convoluted, unusable APIs possible. Specifications accompanied by half a*rsed, unfinished implementations. Specifications that never show up in a Java edition. Specifications for pet projects and niche markets that won’t catch on in hundred years, but someone ponied up the money to buy himself a vanity / marketing JSR.

    The JCP needs to be dissolved. Its managers should be banned from using the word “community” for the next 25 years. API designers should be banned for life from ever again developing an API or touching a programming language.

    The JCP has done more harm to Java than even Microsoft. It deserves to die.

  8. Craig Doremus says:

    Thanks for doing this. Another thing that can be done is to push Oracle to nominate Bob Lee for the spot that Hologic lost. Bob would be a good advocate for the things you propose in this letter.

  9. Eric B says:

    I believe a change in the JCP should include removing any RI and TCK requirements. This is the main cause of current problems/politics.

    Replace these with a “Verification/Validation ‘Spec'” or include this in the standard itself to insure meet the standards.

    Then you don’t have to worry about patents within implementation products (RI or TCKs).

  10. […] the Java EE 6 platform specifications were finalized. In my opinion – because of the current state-of-affairs in the JCP – it was just not a safe bet to promise integration with other technologies that might not have been […]

Leave a Comment

Please note: In order to submit code or special characters, wrap it in

[code lang="xml"][/code]
(for your language) - or your tags will be eaten.

Please note: Comment moderation is enabled and may delay your comment from appearing. There is no need to resubmit your comment.