JPA 2.0 中的动态类型安全查询

核心提示： Java Reflection API 在 Java 语言诞生时就被引入（对于一种常见的多用途编程语言而言，这曾经是一个非常前沿的概念），JPA 2.0 中的动态类型安全查询(9)，但是经过多年的发展才认识到强类型系统的用途和强大之处，JPA Metamodel API 将强类型引入到持久化实体

Java Reflection API 在 Java 语言诞生时就被引入（对于一种常见的多用途编程语言而言，这曾经是一个非常前沿的概念），但是经过多年的发展才认识到强类型系统的用途和强大之处。JPA Metamodel API 将强类型引入到持久化实体中。例如，持久化实体在语义上区分为 MappedSuperClass、Entity 和 Embeddable。在 JPA 2.0 之前，这种语义区分是通过持久化类定义中的对应类级别注释来表示的。JPA Metamodel 在 javax.persistence.metamodel 包中描述了 3 个独立的接口（ MappedSuperclassType、EntityType 和 EmbeddableType ），以更加鲜明的对比它们的语义特征。类似地，可以通过接口（比如 SingularAttribute、CollectionAttribute 和 MapAttribute）在类型定义级别上区分持久化属性。

除了方便描述之外，这些专门化的元模型接口还有实用优势，能够帮助构建类型安全的查询从而减少运行时错误。您在前面的例子中看到了一部分优势，随着我通过 CriteriaQuery 描述关于连接的例子，您将看到更多优势。

运行时作用域

一般而言，可以将 Java Reflection API 的传统接口与专门用于描述持久化元数据的 javax.persistence.metamodel 的接口进行比较。要进一步进行类比，则需要对元模型接口使用等效的运行时作用域概念。java.lang.Class 实例的作用域由 java.lang.ClassLoader 在运行时划分。一组相互引用的 Java 类实例必须在 ClassLoader 作用域下定义。作用域的边界是严格 或封闭 的，如果在 ClassLoader L 作用域下定义的类 A 试图引用不在 ClassLoader L 作用域之内的类 B，结果将收到可怕的 ClassNotFoundException 或 NoClassDef FoundError（对于处理包含多个 ClassLoader 的环境的开发人员或部署人员而言，问题就复杂了）。