Why JSR 170?

The Java Content Repository API (JSR-170) is an attempt to standardize an API that can be used for accessing a content repository.

Various CMSs from different vendors have been on the market for quite some time, and all of these CMSs ship their own version of a content repository. The problem is, each CMS vendor provides its own API for interacting with the content repository shipped with that vendor's CMS. This is a problem for the application developer, since he has to learn a particular vendor's API and potentially tie up his code with one particular CMS implementation.

JSR-170 tries to solve this problem by standardizing the API that should be used for connecting to any content repository. With JCR-170, you develop code by only using the javax.jcr.* classes and interfaces. This should be able to work with any JSR-170 compliant content repository.

You can think about JSR-170 as a JDBC-like API for content repositories, allowing you to develop your program independently of any particular content repository implementation. At runtime, you can configure this program to work either with a natively JSR-170 compliant content repository (e.g., Communique or Apache Jackrabbit) if your repository is not natively JSR-170 compliant (e.g., Documentum or Vignette), then you can use some kind of repository-specific JSR-170 driver that takes care of converting your JSR-170 method calls to repository-specific method calls.

The JCR-170 API has different advantages for different stakeholders in content repository space.

Developers do not have to spend time learning each vendor's repository-specific API. Instead, once she is comfortable with JSR-170, a developer should be able to work with any JSR-170 compliant content repository. In the past, developers had to make choice between a CMS with great features and poor development tools, or one with great development tools but poor features. Now that the interface between content repository and CMS applications is standardized, you can choose the best choices from both worlds.
Corporations won't have to face problem of vendor lock-in. More commonly, many corporations have more than one CMS either because different departments choose to use different CMSs in the past, or because some acquired company used a different CMS system. In the past, corporations spent a lot of money getting these different systems to interact with each other. With JSR-170, they can be assured that same application will work with all CMSs.
CMS vendors were forced to develop and maintain their own content repository implementations, which meant lots of infrastructure code. Now they can leave development of the content repository to some other vendor and concentrate more on their core competency: developing CMS applications.