The Java Persistence API (JPA), version 1.0, released in May 2006 as part of the Java EE 5 platform, represented a significant leap forward for architects and developers wanting to persist Java state to relational databases using standard metadata and a portable API. While a standard ORM specification was somewhat overdue, when it did finally arrive it brought with it not only the database portability that was inherent in existing ORM products, but also the ability to plug in different vendor implementations.
Although some were satisfied with the proprietary APIs offered by products like JBoss Hibernate and Oracle TopLink, the more experienced and forward-thinking application developers moved over to using JPA. The only problem was that JPA 1.0 did not have all of the features that were found in the proprietary APIs.
The solution, however, was far from rocket science, and involved simply using JPA for the features that were needed and available there, and reverting to the proprietary API for the few features that were missing from the standard. The result was that changing the underlying implementation only required porting a small amount of code coupled to the existing implementation. But it was not ideal. The JPA 1.0 expert group had only a limited period of time in which to start from nothing and end up with an entire persistence standard. As a useful and achievable goal, it endeavored to include 80-90% of the features supported by the existing ORM frameworks. The rest would have to be added in subsquent releases.
The JSR 217 expert group is currently engaged in the next phase of the JPA progression. It will deliver, to be released as part of Java EE 6, version 2.0 of JPA. It will also include most of the features that people missed and asked for in JPA 1.0, such as increased modeling flexibility, additional object-relational mapping capability, more locking options and a runtime Java API-based query language. In this multi-part series we will discuss some of these new features, how they are being added to the specification and how users will be able to make use of them.
Although many of these features have been discussed, and are close to being concluded, some have not yet been, and are yet to be discussed within the group. Even those topics for which discussion has subsided are not set in stone, and may yet change. So while this series will give you a taste of what’s coming, it offers no guarantees that the features it describes are in their final released form, or even that they will necessarily be included at all!
On the other side, neither should the features described in these articles be assumed to be a complete list of the new feature set. Group members regularly make suggestions for new features that were not on the agenda but are nonetheless of enough value to expend the effort to specify.