There has been a lot of talk of late regarding the demise of the Java Content Repository (JCR) specification and what to do when a standard does die off.  Much of this is blamed on the emergence of CMIS as a standard, but that is just a contributory factor.  Many Content Management specifications and standards have withered over the last decade without a standard positioned to replace them.

Evolution

Everyone reading this is probably fairly familiar with the concept of evolution.  While there are those who have strong opinions regarding evolution, it is a phenomenon that is readily apparent in the world of Content Management.

In the mid 90s, the ODMA standard came into existence.  It was a great standard.  It allowed for native integration of any desktop application into a content repository, no coding involved.  Think on these features that any application that was ODMA compliant presented:

• No coding
• Users couldn’t save things outside of the repository without custom code
• No plug-ins or add-ons required, allowing desktops to be secured.

It may not seem like much, but as all previous methods usually involved macros, limiting the applications that you could link to a repository, it was a godsend.  All of the sudden, we weren’t managing desktops or worried about content not being saved properly.

Then came the web.  As it evolved, applications moved to the browser.  ODMA’s weakness was that it required a local CMS front-end to be installed for the desktop applications to leverage ODMA.  Once everyone move their desktop applications to the web, that tight integration was lost.

There was a large step back in adoption rates.  When local is not only the default option, but the easiest one, it gets used.  It has taken years to get the integrations close to what they were in the days of ODMA.

That said, the web interfaces were a solid step forward in the evolution of Enterprise Applications.  Now we wouldn’t dream of installing a broad-based application that didn’t have a robust web interface.

It is all evolution.  The business world evolved beyond ODMA.  It is still in use, but it is rare due to the sparse nature of those desktop CMS applications.

JCR vs Evolution

All standards have a weakness.  JCR’s initial first weakness was its strong link with Java.  That works great for some systems, but not others.  One example is that SharePoint system you hear so much about.

Of course, using it with your common desktop applications is another challenge.  The most common suite is also made by Microsoft.  There is another hurdle.

Mind you, it wasn’t designed for integrating the desktop.  It is for writing custom applications and integrations on the back-end, using a common interface.  Like CMIS, JCR could limit the amount of code needed to write when integrating systems.  All you needed was the one JCR API.

CMIS has come along, simplifying things.  It works cross platform, but it is not as feature rich as JCR yet.  That said, it has better querying capabilities which is important if you are looking for generic methods of finding content in multiple repositories.

The questions remain.  Is JCR going to die?  Did CMIS kill it?

A Clear Example

Nuxeo recently announced that they were dropping support for the JCR spec.  Why?  The Director of Nuxeo’s R&D, Florent Guillaume, explains it clearly in a recent post.  Essentially, they have a good API that matches how Nuxeo works very well and they support CMIS.

Think on that.  They support a standard that allows them to be interoperable in the same manner that JCR did.  They also have a way for someone to write detailed, Nuxeo specific, applications at a much lower level of the technology stack.  JCR was redundant on many levels.

Now many people will point out that JCR does a lot more than CMIS.  One would expect that for a 2.0 specification when comparing it to the initial release of a standard. The question is, “Are all those features supported by all vendors?”  If you are going to write interoperable code against multiple repositories, you need to make sure that all of the features are available.

The Future of JCR

I heard someone compare JCR to a zombie.  That seems a little harsh.  It is more like a teenager that was just diagnosed with a degenerative disease.  They never really achieved the full vision that their parents envisioned and never will.  They still have the potential be productive members of society, but as the years go on, it will take more support by others for that impact to be felt.

JCR still has a place.  It still works.  It is also a specification for a repository and not just for interoperability.  I expect it will keep on for quite some time.

While alive, JCR’s use will diminish.  As CMIS proves itself and matures, the interoperable reason to use JCR will likely be all but eliminated.  Over the course of years, the usage will diminish, but it will likely continue to survive as long as people and vendors make use of the Apache Jackrabbit repository.