Java Persistence API （JPA） 2.0版目前已进入最终建议草案阶段，这一版对规范作出了重要更新，为条件查询（criteria queries）增加了一个API，一个元模型API，并且支持Bean Validation [JSR 303]。
这一版的条件查询（criteria query）API允许通过调用Java对象的方法来创建查询，而不是把JPA-QL嵌入到字符串中，由JPA实现进行处理。在第一个公开草案中，API 本身是基于字符串的，专家组收到许多反馈建议他们研究一下改善该议案的类型安全性的可能行。Gavin King提出了一个建议，该建议建立在现有基于字符串的API之上，利用Java 6 中的javax.annotation.Processor对应用程序中的每一个持久类都自动产生一个元模型类型。结合泛型，这一机制提供了一种有效的 变通方法，解决了Java缺乏针对类的方法和属性的类型安全元模型的问题。每当使用代码生成器时，就会引起争议，因为其产生的代码往往晦涩难懂，而且通常 需要特定IDE的支持。但是在这里，因为产生的代码只是用于类型信息，保持其整洁还是有可能的。例如，给定一个持久类：
import java.util.Set;
import java.math.BigDecimal;
@Entity public class Order {
@Id Integer orderId;
@ManyToOne Customer customer;
@OneToMany Set lineitems;
Address shippingAddress;
BigDecimal totalCost;
...
}
相应的典型元模型类，Order_，如下所示：
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
因为Java 6包含注解处理器（annotation processor），因此这一变化并不需要特定的IDE支持——IDE可以把注解委托给由编译器触发的注解处理器，并且在处理过程中产生元数据模型。
元模型可以通过一个API来查询，该API指定了接口，用于动态访问持久状态元模型和持久单元托管类（Managed classes）的关联关系。它还不能提供支持访问ORM信息，尽管这已在未来更新的规划之中。该接口由持久化提供商实现，可以通过 EntityManagerFactory.getMetamodel和EntityManager.getMetamodel方法来访问，其返回的是提 供商针对javax.persistence.metamodel.Metamodel接口的实现类。
King 最近建议进 行进一步重构，把类型安全性一直扩展到查询结果集，给CriteriaQuery和Query都增加一个类型参数。这就使开发者可以直接访问类型安全的实 体列表或封装，但对于基于JPA 1.0的项目，这将导致编译器警告，因为javax.persistence.Query目前没有这个类型参数。
类型安全方法曾在专家组中引发过争论。JPA 2.0规范的领导Linda DeMichiel在其博文中记述了对String和类型安全方法的比较，文中她是这样描述的：
“在基于元模型API和基于字符串API相比孰优孰劣的几番争论之后，我们[专家组]决定采用类型安全的API，但是如果开发者愿意，我们也提供了基于字符串方法的选项。”
这两个选项之间的主要区别是，基于字符串的属性名可以用来指定joins和navigation中引用的属性。结果是这些查询与类型安全版拥有相同的语义，但是却没有相同级别的类型安全性。
JPA 2.0还支持在Java持久化应用中使用Bean Validation[JSR 303]。托管类（实体、映射的超类和可嵌入类）可被配置包含Bean Validation约束。使用这些约束的自动校验是这样实现的，指定Java持久化应用程序将校验委托给基于pre-persist、pre- update和pre-remove实体生命周期事件的Bean Validation实现。
专家组热切期望接到来自社区的反馈，如有何意见可发送至jsr-317-pfd-feedback@sun.com。
来自: .Net世界