Articles with titles like “Goodbye JCR, Hello CMIS” have been growing in numbers. The voices suggesting that the Java Content Repository standard is no longer relevant in a market dominated by non-Java content management systems are growing. Is JCR really dead?

JCR vs. CMIS

The Java Content Repository, JCR, is a standardized API for accessing repositories. The standard was defined using the Java community process as JSR-170, finalized in 2005, and JSR-283, finalized in 2009. The goal of the JCR was to allow organizations avoid the costs and complexity associated with one-off vendor specific integrations by providing a common vocabulary and technique to access content repositories. Leveraging the JCR means that applications can use the API to bi-directionally access content stored in various repositories, separating application functionalities from those specific to repositories.

2009-12-JMarks-JCR.jpg

JCR overview


The most recent content management standard is Content Management Interoperability Services, CMIS. CMIS is a protocol standard published in 2008 and accepted as an Oasis standard in 2010. CMIS provides common web services and RESTful web 2.0 interfaces, making it both platform and language independent.

CMIS enables users to perform standard CRUD operations (create, read, update, delete) against any compliant repository, regardless of the underlying repository architecture. CMIS, although new, appears to be very popular. The New York Times even mentioned it.

Both standards promise to enable platform-agnostic content mashups, easier cross-silo federation, rapid application development made possible by a common API, cleaner abstraction of content and content services from application logic. It shouldn’t be too surprising that the technologies boast the same benefits. Many of the originators of CMIS, except Microsoft, were also on the JSR Expert Committees for the JCR.

JCR Adoption

JCR has achieved some adoption, but not to the extent its originators likely envisioned. This might be because the content management market has plenty of non-Java products. CMS vendors that have adopted the JCR usually support a subset of features. Not all upgrade to the latest JCR 2.0. Apache Jackrabbit, the reference implementation of JCR, is essentially the only product that have implemented virtually all of the JCR. Many Web CMS vendors have their versions of JCR support, including open source Magnolia, Jahia and Hippo.

The JCR has, however, transcended its Java-only origins. David Nuescheler, JCR spec lead and VP Products & Technology at Adobe, stresses this point:

JCR has been language-agnostic for a long time despite the "J" in its name and has
been ported to many languages and environments including PHP, Perl, JavaScript, .NET, etc.

In addition, JCR connectors now exist for content management systems like SharePoint and EMC Documentum. Will JCR adoption continue at its current pace or contract now that a new language-agnostic standard has been introduced? The industry does not have a unified opinion on this matter. In fact, in many cases, opinions are opposite.

According to David Caruana, Chief Architect at Alfresco Software and OASIS CMIS Tech Committee member,

JCR adoption will decrease. This will be driven by the lack of investment by content repository vendors. JSR-283 (JCR v2.0) was published in Sep 2009 and no vendor has implemented it on top of their existing content repository. The only available implementations are pure implementations of the specification such as Apache Jackrabbit. This is an indication of how difficult it is to implement.

Boris Kraft, CTO for Magnolia CMS, disagrees:

From a software developer perspective, JCR provides a fantastic level of services. If you write anything that needs fine grained security, versioning, observation etc., then you'd need to have a very good reason not to look at leveraging what is there. Going forward, the fact that JCR comes to the PHP crowd should make a difference.

Adriaan Bloem, analyst at Real Story Group, thinks JCR adoption will increase for a different reason – the focus of the European Union government on open source and standards. Since JCR, implemented as Jackrabbit, fulfills both of those criteria, it might very well make the adoption list.

Is CMIS a JCR Killer?

Proponents of JCR and CMIS say the technologies don’t compete directly. But, JCR with Apache Sling at a cursory level looks a lot like service-centric CMIS.

cmis-jcr_035_thumb.png

JCR vs CMIS scope


Bloem doesn't think CMIS will cause the demise of JCR:

The JCR has a completely different purpose than CMIS. It's repository vs. connector. I don't think CMIS impacts JCR adoption because the rationale for using CMIS tends to be different from the rationale to use JCR. Much like, say, ODBC adoption doesn't impact MySQL adoption. They have different purposes and different reasons drive their use.

If organizations are unsure, there is really no need to consider CMIS and JCR mutually exclusive. Apache Chemistry implements CMIS on top of JCR.

Standards Support in the Real World

The CMS market has not yet reached a level of maturity where most organizations understand or demand compliance with the content management standards. Currently, although organizations should care, many are overwhelmed by the seemingly limitless buzzwords in the content management space.

With that in mind, JCR is not yet headed the way of Betamax, but what do you think? Has JCR reached the end of road?