相关链接

JPA 2 元模型 是 JPA 2 中类型安全查询的基础。生成的类允许您使用静态字段引用来引用实体属性，而不是字符串。 （元模型类是匹配的实体类的完全限定类名，后面跟着一个下划线 (_))。

正如你们所看到的，Java EE 6 已经进入最终发布阶段。现在您可以从 Contexts and Dependency Injection、Bean Validation、Java Persistence API 2 和 Java Servlet 3 规范中下载最终发布版jcp.org，并阅读整个平台的链接 javadoc。如果您还没有检查，这也是查看现在包括 CDI 集成的 Java API for RESTful Web Services 规范的好机会。

现在 Bean Validation 正式成为 Java EE 6 的一部分，并且 Java EE6 已经正式投票通过 YES，让我们看看 Bean Validation 如何与整个生态系统集成。

IntelliJ 现已支持我之前在博客中提到的新的 JPA 2.0 类型安全的查询功能。我曾在以下博客中讨论过这个话题：这里 和 这里。确保这些功能与工具完美配合是非常重要的，因此看到工具供应商早早地介入真是太好了。

哈哈，无意间发现了这个。有趣的是，在“持久化战争”结束三年后，在 JPA 几乎在 Java 开发的每一个角落都取得了巨大成功的情况下，阴谋论者仍然存在，他们暗中暗示“像 Oracle、IBM、RedHat 等商业组织在 RDBMS 技术或销售应用服务器方面有自己固有的利益”。

Linda 已经撰写了关于 新的类型安全查询 API 的文章。我之前在以下博客中讨论了这一举措背后的思路：这里 和 这里。

你以为这是不可能的吗？当然可以！尽管 Seam 开发团队鼓励你使用 Hibernate 作为 JPA 提供程序，但 Seam 能够与任何 JPA 提供程序一起工作。本文将向您展示如何做到这一点。

在JPA小组中，关于我的类型安全的查询提议已经有很多讨论。我新喜欢的Java语言特性是javax.annotation.Processor。Java 6的注解处理器是从JDK 5中存在的APT工具派生出来的，但它已经内置到了javac。实际上，“注解处理器”这个名字有点误导，因为这个特性与注解只有偶然的联系。这个Processor实际上是一个相当通用的编译器插件。如果你像我一样，以前从未是代码生成的粉丝，现在是时候重新考虑了。Java 6Processor可以

JPA 2.0规范的公开草案已经发布，并包括了一个备受期待的特性：一个API，允许您通过调用Java对象的方法来创建查询，而不是通过将JPA-QL嵌入到由JPA实现解析的字符串中。您可以在Linda的博客上了解更多关于公开草案提出的API的信息。