You already heard that JCR (Java Content Repository) is an interface to access the file system, a relational database or an XML document. But is it a better Hibernate (which is a generic interface for RDBMS), only more generic? No, that is not correct.

JCR is a java interface to access - as the name says - content only. Content? That means most of the times web content and but also other hierarchically stored data. The content is stored in a repository. The repository can be a file system, a relational database or an XML document. The internal structure of JCR data looks similar to an XML document, that means a document tree with nodes and data - with a small difference in JCR the data is stored in "property items".

Or better to cite the specification of JCR: "A content repository is a high-level information management system that is a superset of traditional data repositories."

Remember how the data for your web site is stored? The images are probably in a file system, the meta data is in some dedicated files - maybe in XML - the text documents and pdfs are stored in different folders with the meta data in an other place (a database?) and in a proprietary structure. How do you manage to update these data and how do you manage the access rights? Probably your boss asks you to manage different versions of each document? The larger your web site is the more you need a Content Management Systems (CMS) which tackles all these issues.

These CMS solutions are sold by different vendors and each vendor provides its own API for interfacing the proprietary content repository. The developers have to deal with this and need to learn the vendor-specific API. If one time in future you wish to switch to a different vendor everything is different, you have a new implementation, a new interface etc.

JCR provides a unique java interface for interacting with both text and binary data, for dealing with any kind and amount of meta data your documents might have. JCR supplies methods for storing, updating, deleting and retrieving your data, independent of the fact if this data is stored in a RDBMS, in a file system or as an XML document - you just don't need to care about. The JCR interface also defines classes and methods for searching, versioning, access control, locking, and observation.

Furthermore an export and import functionality is specified so that a switch to a different vendor is always possible.

eXo fully complies the JCR standard JSR 170 and therefore by choosing eXo JCR you use a vendor-independent API. That's means you could switch any time to a different vendor. Using the standard lowers your lifecycle cost and reduces your long term risk.

Of course eXo does not only offer JCR, but also the complete solution for ECM (Enterprise Content Management) and for WCM (Web Content Management).

In order to understand the theory of JCR and the API please read some external documents about this standard: