Java Persistence API 2.0—A Great Start Gets Better (TS-4945)

One of the significant enhancements introduced last year in the Java Platform, Enterprise Edition 5 (Java EE 5) was the Java Persistence API, sometimes called simply Java Persistence. The API, which was packaged as part of Enterprise JavaBeans (EJB) technology 3.0 (JSR 220), gave Java developers a much easier way to access and manipulate relational data. Aptly named, the API deals with persistence: the way relational data is mapped to Java objects (or persistent entities), the way that these objects are stored in a relational database so that they can be accessed at a later time, and the continued existence of an entity's state even after the application that uses it ends. In addition to simplifying the entity persistence model, the Java Persistence API also standardized object-relational mapping.

The reaction to Java Persistence has been extremely positive. Developers no longer have to create lengthy, complicated deployment descriptors -- a common bugaboo in applications that use EJB technology. Annotations and defaults replace a lot of that cumbersome code. Also, creating and using entities has been dramatically simplified. Persistent entities are simple, concrete, Plain Old Java Object (POJO) classes that developers can instantiate just as they would any other simple Java technology class. By comparison, the old way of dealing with entities required developers to implement various abstract classes, interfaces, and interface methods -- whether they used those methods or not. And there's more. The API offers capabilities, such as inheritance and polymorphism, that were not previously available, as well as a highly functional Java Persistence Query Language.

Currently, the Java Persistence API is available in an EJB 3.0 container within a Java EE implementation. However, the API can also be used outside the container within Java EE and can even stand alone in the Java Platform, Standard Edition (Java SE). The API also provides support for pluggable, third-party persistence providers -- it's possible to use a persistence provider that's different than the one provided by the EJB container.

Java Persistence has had a great start, with strong acceptance by the Java community. As speaker Linda DeMichiel pointed out in this session, "What we did, I think, was really pretty amazing for a first release." She went on to say that "In fact, we exceeded our expectations in terms of what we thought we could accomplish in the first release." However, DeMichiel also pointed out that "It's important to keep in mind that this is still effectively a 1.0 release. It has some limitations that we were very aware of in the Expert Group as we concluded this work. We've got some open issues, a few ambiguities, and a couple of bugs we uncovered as vendors were developing and certifying their implementations." She added that there's some open functionality that is left as vendor extensions, which gets in the way of portability, and that the 1.0 release is missing a few pieces.

DeMichiel is a senior architect in the Java EE platform group at Sun Microsystems and is the chief architect for EJB 3.0 technology and the Java Persistence API. As the specification lead for JSR 220, she was responsible for launching and leading the initiatives for EJB 3.0 and the Java Persistence API under the Java Community Process program. Who better to give a talk on where Java Persistence is headed?

And so DeMichiel was onstage before a very large and enthusiastic audience to provide an glimpse of things likely to come in Java Persistence 2.0.

The objectives for Java Persistence 2.0 are these:

• Solidify the standard and make it more solid.
• Reduce the areas of nonportability.
• Standardize optional functionality.
• Add the missing pieces -- many of them requests from the community for needed features.

This will result in a brand new JSR for Persistence, one that will be decoupled from EJB 3.1.

Those objectives translate into a set of proposed enhancements that the Java Persistence 2.0 Expert Group is considering. Here's a peek into some of those enhancements.

Although Java Persistence has rich data-modeling capabilities, there's room for more flexibility. DeMichiel mentioned a number of things that could make data modeling through the API more flexible. One of these is adding support for multiple levels of embeddables. An embeddable object is a persistent object that can be embedded in another entity.

When the object is embedded, it's stored as part of the entity and shares the entity's identity. A common example of this is an embeddable Address object that is embedded in an Employee entity or a Customer entity. Currently, an embeddable object cannot be embedded in another embeddable object. However, the Expert Group is investigating support of that type of multilevel embedding. DeMichiel showed an example of how this enhancement would allow a developer to create an embeddable object such as a zip code and then embed that into an embeddable Address object. The resulting hierarchy of embeddable objects could then be embedded into a entity.

Another proposal regarding embeddable objects is to enable mapped superclasses for embeddables. All the information in a mapped superclass is applied to the entities that inherit from it. The proposal would enable embeddable objects to inherit state information from a mapped superclass.

Two other proposals that would make for more flexible data modeling are support for persistence in ordered lists and allowing multiple access types for entity retrieval. Java Persistence currently supports ordered lists, but the sorted data in the result is nonpersistent. Many developers have asked that the order be maintained by the persistence provider. DeMichiel said that because of that widespread request, "It's very likely that we should provide that functionality as well."

The multiple access proposal requires a little background. In Java Persistence, an entity can have field-based or property-based access. In field-based access, the persistence provider accesses the entity's state directly through its instance variables. In property-based access, the persistence provider uses JavaBeans-style get/set accessor methods to access the entity's persistent properties. Currently, Java Persistence allows only a single access type for an entire entity hierarchy. The proposal would allow different parts of an entity hierarchy to have different access types.

DeMichiel showed an example in which an embeddable Address object was marked as requiring property-based access, using a new @AccessType annotation. If the Address object is embedded in an entity such as a Customer entity, the other parts of the Customer entity could have a different access type.

Currently, Java Persistence does not mandate support for foreign key mappings in unidirectional one-to-many relationships. Suppose you have two tables, one a Customer table that contains information about customers and the other an Orders table that contains information about customer orders. Java Persistence does not yet mandate support for a foreign key to establish a one-to-many relationship between customers in the Customer table and orders in the Orders table. This leaves developers with the single option of making one-to-many relationships bidirectional, something many developers don't necessarily want to do.

DeMichiel pointed out that setting up a one-to-many relationship using a foreign key is an obvious data-modeling strategy. With this support implemented, you could establish a one-to-many relationship between customers and orders by setting in the Orders table a foreign key that points to the primary key of the Customer table.

Another object-relational mapping enhancement under consideration would make the single-table-per-class inheritance-mapping strategy a full-fledged part of Java Persistence. Some background: an important capability of the Java Persistence API is its support for inheritance. You can map a hierarchy of entities, in which one entity subclasses another, to a relational database structure, and you can submit queries against the base class. The queries are applied against the entire hierarchy.

Three mapping strategies are now available for an entity class hierarchy: single table, joined hierarchy, and single table per class. In the single-table strategy, the base class and its subclasses are mapped to a single table. In the joined hierarchy strategy, the attributes of the base class are stored in a single table, and the attributes of the subclasses are stored in separate tables. In the single-table-per-class strategy, each class is mapped to a separate table. Up to now, a persistence provider was not required to support the single-table-per-class strategy. DeMichiel said that "This is the way that you will see databases modeled, so it needs to be addressed." The Expert Group is now considering making the strategy a requirement for Java Persistence providers.

Java Persistence includes a highly functional query language called Java Persistence Query Language, which is a superset of an earlier query language in EJB technology called Enterprise JavaBeans Query Language (EJB QL). DeMichiel said that EJB QL "has stood up remarkably well." It's been a part of container-managed persistence that's been successful.

DeMichiel added that "Java Persistence Query Language added considerable functionality to the earlier version of EJB 2.0." Though a marked improvement over EJB QL, Java Persistence Query Language has some limitations. DeMichiel noted that the SELECT clause is too constrained. For example, it supports only aggregate functions. Also, there are some unnecessary restrictions on parameter usage.

Another limitation is that Java Persistence Query Language queries are always polymorphic. That is, when you submit a query on a base class, the query is applied against the entire entity hierarchy—an encompassing action you might not always want. The Expert Group is looking into eliminating these limitations. If so, one of the things you would be able to do is submit a restricted polymorphic query like the following:

SELECT e.name
FROM Employee e, e.dept d
WHERE d.name = 'Engineering'
AND CLASS(e) IN ('Contractor', 'Part Time')

Here, the persistence implementation applies the query only to selected entities in the hierarchy.

Another improvement in the Java Persistence Query Language would allow for criteria-based queries. This type of query, already available in persistence frameworks such as Hibernate and TopLink, allows you to construct queries by adding criteria nodes. Here's an example of a criteria query:

CriteriaQuery cq = em.CreateCriteria(Customer.class);
cq.add(Restrictions.eq("status", "preferred"))
	 .add(Restrictions.eq("address.citystatus", "New York"))
  .addOrder(Order.asc("name"));
...

Some of the other things under consideration by the Expert Group include the following:

• Access to the unfetched state of detached entities. In Java Persistence, entities are managed by an EntityManager within a persistence context. When the persistence context ends, an entity is said to be detached and can no longer access relational data sources. Currently, access to the unfetched state of a detached entity is not defined in the Java Persistence API specification. It's handled differently by different persistence providers. The Expert Group aims to standardize this area.

• Simplifications for application-managed persistence contexts as well as some extensions for container-managed persistence contexts. The latter would include things such as support for conversations with web services and pluggable contracts.

• Support for the Bean Validation specification (JSR 303). This JSR should simplify the way that developers request validation of JavaBeans data—for example, developers can use annotations to request validation. The objective here is to leverage the JSR, where appropriate, in Java Persistence.

DeMichiel ended by presenting a one-slide status report and roadmap for Java Persistence 2.0. The JSR should be posted shortly. DeMichiel said that she'd like to be able to get going with an Expert Group in June. She also said that the goal is alignment of Java Persistence 2.0 with Java EE 6, so it should be available in that timeframe.

DeMichiel also gave an alias address where developers can submit Java Persistence 2.0 feature requests: persistenceNoSpam-feature-request@sun.com. The "NoSpam" part of the alias name alludes to the fact that the alias will change if too much spam is submitted. DeMichiel encouraged the audience to use the alias. "In the past, we found it extremely helpful to get developer input on what you folks need most. So please send feedback."