Latest Posts

Archives [+]

Apache leaves the JCP, what's next?

Written by David Nuescheler and Bertrand Delacretaz

The Apache Software Foundation (ASF) recently announced ( that it is leaving the Executive Committee of the JCP ( and that it will be "removing all official representatives from any and all JSRs".

In this post, we present our perspective on the impact of this decision for Java in general, and more specifically on JCR - the Java Repository API on which our products are based.

Impact on future Java API specs

As David's graph below shows, JCP activity has been going down to very low levels in recent years.

New JSRs submitted, 1998-2010

This might be due to uncertainty about the JCP's future since the Apache/Sun dispute started ( in 2006, but also very probably to a lack of need.

The Java language is a mature one, which has found its (large) niche. Do you really care about improvements in Java SE 7 and 8? We don't see much enthusiasm and the vast majority of programmers seem to be happy with Java SE 5 or 6.

In the API space, OSGi for example, brings real innovation, independently from the JCP. The OSGi alliance ( that manages it is working fine. As with any API spec that's outside of the JCP, OSGi is not allowed to use package names starting with javax, but...did you even notice that? It doesn't make much of a difference.

Many Java APIs are also being developed outside of the JCP, at the ASF, in other open source organizations and in industry consortiums. Their specification processes might not always be as formalized as the JCP's, but as long as one gets a versioned set of documented Java interfaces that a group of experts agrees on, along with a test suite, people are happy. This looks sufficient to us for the evolution (as opposed to a revolution, which is not needed) of the Java ecosystem.

So, on one hand the need for new Java APIs is not as big as it used to, and on the other hand there are other places where APIs can be developed.

Even a totally inactive JCP wouldn't have a serious impact on future Java APIs, in our opinion.

Impact on Java in the content management space

We don't think the JCP and the ASF going separate ways will have any impact on enterprise software in general and in the content management space in particular.

There even may be surprisingly little impact on Java based Apache projects. Apache Jackrabbit, which has been widely adopted as infrastructure for many content management related projects, will continue its development as planned.

Beyond Jackrabbit and Apache Sling, there are a large number of Java based content management projects outside the ASF which are not impacted, and we continue to see a vibrant Java content management community.

Impact on JCR

There are some minimum requirements put on spec leads by the JCP in terms of licensing. Since it is up to the spec lead of a JSR, the licensing varies from spec lead to spec lead.

As the spec lead for JCR (JSR-170, JSR-283 and ongoing work on JSR-333) we opted for the most open licensing we could use for those JSRs:

The JCR APIs are also available from the central Maven repository under, without requiring any click-through or other agreement.

The official test suites (TCK) for those JSR specs have been contributed to the Apache Jackrabbit project under the Apache CCLA ( and as such are freely available to anyone under the permissive and business-friendly Apache License.

Our ongoing work on JSR-333, the next release of the JCR API, is also unaffected by the ASF leaving the JCP. We are acting as Day/Adobe employees or individuals there, not as representatives of the Apache Software Foundation.

Impact on CQ5 and CRX

As we don't see any impact on JCR, we are not planning any changes concerning CQ5 and CRX in this area. JCR continues to gain momentum in the WCM industry and beyond, so we are looking forward to an even broader use of JCR.


In bad pun mode we could say nothing new under the Oracle.

Apache leaving the JCP is a step that was discussed for years, that helps clarify the situation and might help Oracle be more explicit about their plans for Java. People might need to find other places than the JCP to create new specifications, but our work on existing and in-process JSRs is not affected.

We're happy to have invested lots of energy in keeping the JCR specs that we're leading as open as possible. This helps the community understand that one can produce specifications, reference implementations and TCKs in an open manner, even within the JCP. Openness always pays, when it comes to creating sustainable ecosystems.

Full disclosure: David Nuescheler is a member of the ASF and Spec Lead for JSR 170, 283 and 333, and Bertrand Delacretaz is a member and board member of the ASF. So consider the above as educated but personal opinions, not wearing any particular ASF or JCP hat.



  • By Ross Gardler - 11:19 AM on Dec 15, 2010   Reply
    Actually the Apach/Sun dispute started long before 2006 - it just became public in 2006. In 2002 Sun made a joint announcement with the ASF, saying they would provide access to the TCKs and much more. That announcement, made by Scott McNealy and Rob Gingellon at Java One, was the product of long negotiations.

    You can watch the announcement at

    Sun never provided those licences. The ASF continued to seek them privateley until deciding to go public with the dispute in 2006 as you report.
  • By Stephane Croisier - 9:14 AM on Dec 16, 2010   Reply
    Hi David and Bertrand,

    Thanks for the clarification. In such a trouble Java time, transparant communication is really appreciated. So thanks a lot for your post.

    As you mentionned it, "there are some minimum requirements put on spec leads by the JCP in terms of licensing. Since it is up to the spec lead of a JSR, the licensing varies from spec lead to spec lead." With what is currently happening to the Apache Harmony project, one may question himself about what could happened to Apache Jackrabbit (or other Apache hosted JEE RI project such as Pluto for instance). Oracle may also prefectly decide to slighlty modify the "minimum requirements" put on spec leads at least regarding the possible open sourcing of any future RI or TCK for any new JSR in the future.

    Knowing the fact that you also have to wear a tripple hat (Apache committers/board member + a new, still partially unknown, Adobe position towards open source + a lead JSR position - not including the OASIS CMIS-JCR liaision hat), wouldn't it be the right time to move the JSR-333 out of the Oracle-JCP umbrella to ensure its long term perennity? I am sure you already evaluated all the possible options and got all the necessary warranties from Oracle that what is happening to Apache Harmony can not happen to future releases of the JCR/JSR-333 and to the open source versions of the RI/TCK. But this is still quite hard to understand your current position explaining on one hand that "JCP-is-a-near-death-experience" while simultaneously mentionning on the other hand that "nothing-change-for-next-release-of-the-JCR-under-the-Oracle-JCP-umbrella". Quite a complex excercise!

    In all the cases, whatever the future position and the tactictal move of all parties involved, your ongoing committment and willingness to try to continue to push for an open-source version of the JCR 3.0 is really appreciated. Thanks for all the great work! Let's hope Oracle and its lawyers will not stop your enthousiasm to continue to see the spec evolve under an open source mindset.

    Kind Regards,
  • By Lukas Smith - 11:39 PM on Jan 05, 2011   Reply
    I have emailed David about this already but no reply. Right now I can find no clear confirmation that the JCR spec is in fact available under the Apache license.

    On the JCR page the license is as follows:

    Which is also the text included in the final download.

    However on it says:
    "2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

    The Specification, the RI and the TCK will be available under an Apache-based license, just as they are with JSR-170."

    However aside from this comment and this blog post I can find no indication that this is really true and certainly nothing I find trustworthy enough at this point.