The Java Persistence API (JPA) version 2.0, now in proposed final draft, is a significant update to the specification adding an API for criteria queries, a metamodel API, and support for Bean Validation [JSR 303].
The criteria query API allows the creation of queries by calling methods of Java objects, instead of by embedding JPA-QL into strings that are parsed by the JPA implementation. In the first public draft the API was itself string based and a lot of feedback was received by the expert group suggesting that they explore the possibility of improving the typesafety of the proposal. Gavin King responded with a suggestion which built upon the existing string based API and exploited the javax.annotation.Processor built into Java 6 to automatically generate a metamodel type for each persistent class in the application. Combined with generics, this mechanism provides an effective workaround for Java's lack of a typesafe metamodel for the methods and fields of a class. Whenever a code generator is used it is controversial since they have a tendency to produce code that is very difficult to follow and generally require specific IDE support. In this instance though, since the code is generated just for type information, it is possible to keep it fairly clean. For example, given a persistent class:
import java.util.Set;
import java.math.BigDecimal;
@Entity public class Order {
@Id Integer orderId;
@ManyToOne Customer customer;
@OneToMany Set
Address shippingAddress;
BigDecimal totalCost;
...
}
The corresponding canonical metamodel class, Order_, is as follows:
import java.math.BigDecimal;
import javax.persistence.metamodel.Attribute;
import javax.persistence.metamodel.Set;
import javax.persistence.metamodel.TypeSafeMetamodel;
import javax.annotation.Generated;
@Generated
@TypeSafeMetamodel
public class Order_ {
public static volatile Attribute<Order, Integer> orderId;
public static volatile Attribute<Order, Customer> customer;
public static volatile Set<Order, Item> lineitems;
public static volatile Attribute<Order, Address> shippingAddress;
public static volatile Attribute<Order, BigDecimal> totalCost;
}
Since the annotation processor is included with Java 6 the change also requires no specific IDE support – an IDE can delegate to the annotation processor triggered by the compiler and the metadata model is generated on the fly.
The metamodel can be queried via an API which specifies interfaces for dynamically accessing the metamodel of the persistent state and relationships of the managed classes of a persistence unit. It does not as yet offer support for accessing the object/relational mapping information though this is planned for a future update. The interfaces are implemented by the persistence provider and can be accessed through the methods EntityManagerFactory.getMetamodel and EntityManager.getMetamodel, which return the provider’s implementation class for the javax.persistence.metamodel.Metamodel interface.
King recently suggested a further refactoring that extends the typesafety through to the query resultset adding a type parameter to both CriteriaQuery and Query. This provides developers with direct access to typesafe lists of entities or wrappers but would result in compiler warnings for JPA 1.0 based projects since javax.persistence.Query does not currently have a type parameter.
The typesafe approach has been subject to some debate within the expert group. Writing on her blog, JPA 2.O specification lead Linda DeMichiel provides comparisons between the string and typesafe approaches and states that:
"After many discussions on the pluses and minuses of a metamodel-based API compared to a string-based API, we [the expert group] decided to adopt the typesafe API, but to provide developers the option of using a string-based approach if they prefer."
The main difference between the two options is that string based attribute names can be used as a means of specifying the attribute references in joins and navigation. The resulting queries have the same semantics as the typesafe version but without the same level of typesafety.
JPA 2.0 also defines support for the use of Bean Validation [JSR 303] within Java Persistence applications. Managed classes (entities, mapped superclasses and embeddable classes) may be configured to include Bean Validation constraints. Automatic validation using these constraints is achieved by specifying that Java Persistence applications delegate validation to the Bean Validation implementation upon the pre-persist, pre-update and pre-remove entity lifecycle events.
The expert group are keen to receive feedback from the community which can be sent to jsr-317-pfd-feedback@sun.com