Java Persistence 2.0 Early Draft Available

Java Persistence 2.0 Early Draft We've just released the Early Draft of  the Java Persistence 2.0 specification, so I thought it would be a good time to report on some of the work we've been doing in the JSR 317 Expert Group.

For those of you who are not already familiar with JSR 317 and some of the areas we're planning to address, these are some of the highlights of the JSR-317 agenda:
  • Expanded O/R mappings
  • Improved domain modeling capabilities
  • Additions to the Java Persistence query language
  • An API for criteria queries
  • Standardization of configuration hints
  • Additional contracts for detached entities and extended persistence contexts
  • Support for validation via integration with the work of JSR 303

One of my own goals for Java Persistence 2.0 is what I think of in terms of "solidifying the standard".  Java Persistence 1.0 was a great start and has gotten an extremely positive reception from the community, but—naturally enough for a 1.0 release—it lacks some important features, which has caused users to rely on non-portable vendor extensions.

Java Persistence 2.0 is intended to flesh out the standard with a number of important features requested from the developer community and to give you access to richer functionality while reducing the need for dependence on non-portable code or metadata.

The Early Draft focuses on the areas of object/relational mapping, domain modeling improvements, and some enhancements to the EntityManager and Query APIs.  After JavaOne, we'll be shifting over to the query language area as the focus of our next draft.

Many of the improvements you'll see have been strongly motivated by feedback and requests we have received from developers.  You, the users of this technology, have a significant  influence over our decisions and affect the prioritization of our work by the input and feedback you provide us.

Here are some of the highlights of what we've added in terms of O/R mapping and domain modeling improvements:

Better support for modeling using common Java language datatypes, including embeddable types (e.g., non-entity dependent object types such as Address) and collections of basic types such as String, Integer, etc.  In Java Persistence 1.0, explicitly-mapped collection types (i.e., collections that could be mapped into their own relational tables) were limited to entities, and you either had to store collections of embeddables and basic types in serialized form or rely on vendor-specific metadata.  For embeddable types, in additional to support for collections of embeddables, we've also added support for multiple levels of embedding and for the use of relationships in embeddable classes.

Another frequently requested feature has been support for persistently ordered lists.  Java Persistence 1.0 supports the use of a @OrderBy functionality that allows you to retrieve relationships that are ordered by various attributes as they are retrieved from the database.  This is a very natural approach from a relational point of view.  However, in Java Persistence 2.0 we've also added an @OrderColumn which the persistence provider must use to maintain whatever ordering you assign.  While some of us have a few misgivings about this feature from a database point of view, we have received so many requests for it that we have now added it to the spec.

We've also made support for Maps much more general.  In Java Persistence 1.0, the value of a map needs to be an entity and the key either its primary key or another of its attributes.  In Java Persistence 2.0, the map key and map value can each independently be a basic type, an embeddable, or an entity. This therefore gives support for the modeling of ternary relationships in the database as well as for association tables with additional state.

We've also expanded the supported relational mapping options for existing relationship types.  Unidirectional one-to-many relationships can now be mapped via foreign key mappings (in additional to the join table mappings that are currently supported);  and one-to-one and many-to-one relationships can be mapped via join tables.

Also in terms of relationship modeling, we've now also added support for an "orphan deletion" facility for one-to-many and one-to-one relationships—another feature for which we've gotten quite a few requests.

One of the points of confusion among developers using Java Persistence 1.0 has been how to map database relationships that have overlapping primary and foreign keys.  We've improved this area with the addition of what we've termed "derived identities".  This mechanism allows you to specify the correspondence between relationships (mapped with foreign keys) and primary key attibutes.

Finally,  we've given more flexibility in the combination of access types, both within an entity hierarchy and within a single entity class.

We've also added a number of enhancements to the programmatic APIs:

We have expanded the concurrency control options to include support for pessimistic as well as optimistic locking.  This gives you the ability to grab upfront database locks on selected entities and associated entity data.  In conjunction, we have expanded the APIs that can be used for locking.  Both pessimistic and optimistic locks can now be obtained via the find and refresh methods (in addition to the lock method), as well as through Java Persistence query language queries (both statically and dynamically).

Standardized hints and properties have also been added in support of locking and for other configuration.  Further standardization of hints and properties will occur as we go forward.

Other additions to the programmatic APIs include basic support for second-level cache control as well as a number of additional methods to facilitate tooling.

Send us your input:

When you read the draft, you'll see that there are a number of "Open Issues" that are flagged in the draft, as well as other "Notes to readers" soliciting feedback.   Please send your feedback and comments on this Early Draft and further feature requests to



Great News \\o/
JPA 1.0 was one of the best (if not THE best) ORMs out there, and I hope JPA 2.0 will consolidate this :)

Yet, is it possible to provide a more detailed overview (optimally with examples) of the JPA 2.0 new features, yet in a more developer friendly medium than the Early Draft ?
IMHO, providing such a support will, hopefully, maximize the feedback volume.

With kind regards,

Posted by djo.mos on May 02, 2008 at 10:55 AM PDT #

thanks for the post.

Posted by profesyonelhaber on May 03, 2008 at 07:26 AM PDT #

is the Java Persistence query language related to this?

Posted by justaquestionhere on May 03, 2008 at 08:01 PM PDT #

I'm very glad to see that you were able to get to all of the fringe features in there such as criteria queries. I'm sure that was difficult to decide upon and it is obvoius that the team is communicating well to be able to reach a consensus. Keep listening to the feedback as you move towards the final draft and JPA 2.0 is going to be the best spec the JCP has ever put together!

Posted by Dan Allen on May 04, 2008 at 01:42 AM PDT #

Is it possible to send suggestion for JPA2 using a forum or another open tool instead of email ?

It would be nice that other see my suggestion about JPA2, and I could see and comment about other's suggestions. Just as in the case of JSR-303, look its forum:

Is this possible?

Posted by Javier Paniza on May 05, 2008 at 01:39 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Linda DeMichiel is the Specification Lead for Java EE 7 and for Java Persistence 2.1, and a member of the Java Platform, Enterprise Edition team at Oracle. She was formerly the Specification Lead for JPA 2.0 and for EJB 3.0.


Top Tags
« June 2016