Last month the expert group for the Content Repository for Java Technology API Version 2 (JCR, or Java Content Repository, JSR 283), published an early draft of its specifications.

Artima published a tutorial about JCR 1.0 last year, Catch Jackrabbit and the Java Content Repository API, and we recently caught up with Day Software's David Nuescheler, spec lead for both generations of the JCR APIs. We asked him what new features developers can expect in JCR 2.0:

We are planning to provide extensions in the area of managing a content repository, such as access control, workspace and node administration, and retention aspects of content or repository construction patterns. We also improved upon interoperability of the Content Repository API through the addition of new standardized node types, including node types for metadata information and internationalization.

As well, we provide extensions for content modeling capabilities. Another interesting new feature is the ability to federate repositories, and we now define cross-repository and cross-workspace functionality, too.

Currently, much active development is taking place with existing repository query languages, versioning, and repository node observation. Finally, I should mention work on remoting and client/server protocol mappings.

The JCR API received much developer attention, as it was the first JCP standard to be developed entirely as an open-source project under the Apache Jackrabbit initiative.

Nuescheler noted that the first JCR release was a success, both in terms of design, and also from the point of view of adoption:

I think so far we did not have to reconsider some of the more general decisions we took back then. The short-falls of JCR v1.0 were by design to get a functionally small spec out the door on time. In hindsight, there are only details that we would reconsider.

We are happy to see that only one year after its initial release we have four independent open-source implementations and numerous open-source applications, including Apache Jackrabbit. Some of the others are listed on the JackRabbit project's wiki.

In the commercial realm, we see the first big repository vendors beta-testing their large scale implementations of JCR. While adoption can always be faster, I am thrilled with the JCR adoption. Adoption of JCR certainly beats my expectations by far in comparison to other JSRs.

I think the content repository market is still young and there still are incremental improvements that we can make. We currently see a lot of interest from languages and environments other than Java, such as PHP, .NET, Perl, C, JavaScript, and even WebServices, in adopting JCR. Working with those environments would be one of the most logical expansion paths of JCR in the future.

Where do you think the Java Content Repository API fits into your enterprise architecture?