Ironically, one of the main roadblocks to widespread adoption of JSR-170 (the Java Content Repository standard, now more accurately referred to as JSR-283) may be Java itself. Certainly, the idea of being able to use a common API to access a wide variety of content repositories is a worthy one. But if the API mandates the use of one particular language (such as Java), the Holy Grail of universality immediately takes a hit. Not everyone uses Java, or wants to.

Another important aspect of JCR that bears remembering is that it's silent on the subject of federation. JCR is an API for talking to a content repository (a repository, singular). JSR-170 may enable federation, but it doesn't in any way specify it.

A recent patent filing by BEA Systems speaks to the federation issue as well as the language issue. It proposes the notion of a Virtual Content Repository (VCR), which is a federation of JCR and non-JCR repositories hidden behind a Service Provider Interface (capable of being implemented in any language). The SPI is kind of a meta-API layer (think ODBC). You talk to the VCR through the SPI.

Of course, the problem with this approach (if BEA gets the patent) is that it's patented. It becomes a kind of anti-standard.

If BEA does get the patent, it could be bad news for JCR, precisely because the VCR+SPI approach outlined by BEA is a natural one for achieving federation of JCR-compliant repositories in a heterogeneous IT environment. It's an architectural approach many big ECM vendors would probably want to take with JCR. If that approach is suddenly unavailable, JCR repository integration becomes problematic. And "problematic" is not a word JCR needs to be associated with, at this point.