JPA 2.0的两个类型安全标准API提议

两年前作为Java EE 5的一部分引入的Java Persistence API为对象关系映射提供了一个POJO持久化模型。它作为JSR-220的一部分由EJB 3.0软件专家组进行开发。

Persistence包含三个方面的内容：

1. API，定义在javax.persistence包内。
2. Java Persistence Query Language（JPQL）。
3. 对象/关系元数据。

尽管JPQL使得持久Java对象得到了显著地改善，但JPQL仍然被描述为字符串。这样在查询操作强类型的Java对象的同时，它们自己却是弱类型的。用这种方式构建查询很容易出错，而且需要支持校验、自动补全和重构的特定IDE。

在JSR-317规范下开发的JPA 2.0被包含在Java EE 6中，其目的是通过引入能够提供基于非字符串构建查询的新标准API来解决这一问题。专家组领导Linda DeMichiel已经发表了一篇博文描述了目前的API草案：

“简单说，QueryDefinition对象可以被想成一组相当于查询语义结构的节点：

• 领域（Domain）对象，相当于范围（range）变量和其它JPQL FROM子句的标识符变量
• Where子句谓词，包含一个或多个条件表达式对象
• Select子句，包含一个或多个‘select条目’对象
• Order-by和group-by条目
• 子查询（Subqueries）

等等……”

尽管该提议事实上是在现有JPA机制上前进了一大步，仍有许多人——这其中包括Gavin King，认为类型安全本可以也应该得到进一步改进。King的Hibernate O/R工具是使用类型安全标准API的先驱，并对EJB3产生了重大影响，他已经向专家组提交了自己的建议。他的建议利用了Java 6中引入的javax.annotation.Processor，以允许编译器插件为每个应用程序中的持久类构建元模型（metamodel）类型。King已经在两篇博文（第一篇、第二篇）中描述了他的方法的更多细节，以及他和他的团队目前正在开发的与javac一起使用的原型注解处理器。

专家组正在认真地考虑King的提议，并考虑用它替换当前的审查草稿。DeMichiel告诉我们说：

“讨论主要集中在确保该API给开发者带来更好的开发体验上，静态查询（类型安全方面应当比较好）和动态查询都应如此”。我们也在考虑该元模型（metamodel）生成方面的问题。”

她补充说专家组非常渴望从开发社区听到任何反馈。请在sun.com上的jsr-317-pdr-feedback留下您的任何反馈评论。

查看英文原文：Two Type-Safe Criteria API Proposals for JPA 2.0