Posted by Bertrand Delacretaz DEC 15, 2010
Posted in apache, java content repository, jcr and open source Comments 11
Written by David Nuescheler and Bertrand Delacretaz
The Apache Software Foundation (ASF) recently announced (https://blogs.apache.org/foundation/entry/the_asf_resigns_from_the) that it is leaving the Executive Committee of the JCP (http://www.jcp.org/) 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.
This might be due to uncertainty about the JCP's future since the Apache/Sun dispute started (http://www.apache.org/jcp/sunopenletterfaq.html) 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 (http://www.osgi.org/) 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:
- http://www.day.com/specs/jcr/2.0/license.html
- http://www.day.com/content/dam/day/downloads/jsr283/LICENSE.txt
- http://www.day.com/day/en/products/jcr/jsr-283.html
The JCR APIs are also available from the central Maven repository under http://repo2.maven.org/maven2/javax/jcr, 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 (http://www.apache.org/licenses/cla-corporate.txt) 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.
Conclusions
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.
