JEP 104：类型注释

概括

扩展 Java 编程语言语法中的可注释位置集，以包含指示类型使用的名称以及（根据 Java SE 5.0）类型声明。

允许开发有用的可插入类型检查器来完善 Java 的内置类型系统。

可插入类型检查器的标准化。

三个主要的可插入类型检查器构建在 Java SE 8 上，并使用 Ernst 的“Checker Framework”等框架。
可能，对 JDK 8 代码库的部分应用至少一种注释方案（例如，用于控制空值）。这可能（也可能不会）需要标准化 Java SE 中有用注释类型（例如 @Nullable）的定义。

Java 的注释系统无疑取得了成功。程序员可以在变量、方法和类声明中出现的类型名称上编写注释，然后由企业框架出于配置目的读取这些注释，并由编译器/IDE 出于软件质量目的读取。注释允许从代码中删除样板，并能够在编译时检测到基本错误。

类型使用的注释（而不仅仅是类型声明）可以通过“可插入类型检查器”进行错误检测，从而增强和完善 Java 的内置类型系统。增强的类型系统可以在编译时防止软件质量错误，否则这些错误会在运行时显现出来。示例包括空指针错误、不可变数据的副作用、竞争条件、信息泄漏和非国际化字符串。

JSR 308 对 Java 语言的语法进行了有针对性的低级更改，以允许在大多数可以使用这些名称的地方对类型名称进行注释。这包括 Java SE 7 语言结构中出现的类型名称，例如 try-with-resources 和 multi-catch。

JSR 308 为 JVM 类文件格式定义了新属性，以存储类型名称上的这些注释。最后，它对 java.lang.reflect 和 javax.lang.model API 进行有针对性的更改，以便可以检索类型名称的特定实例上的注释。

JCK 测试 Java 语言的新可注释构造、为方法体级别之上的注释构造新生成的类文件属性以及新的反射 API。
SQE 对方法体级别以下带注释的构造的新生成的类文件属性进行测试。（方法体编译是特定于编译器的，因此没有标准化，因此方法体内构造的注释超出了 JCK 的范围。）
SQE 测试可以在单个可插入类型检查器上进行，但它们不是 JDK 8 或 Java SE 8 的一部分。

风险：广泛的 Java 开发社区对开发或使用可插入类型系统不感兴趣。
假设：可插入类型检查的实用性值得对 Java 语法、类文件和 API 进行重大更改。（除了类型使用的注释之外，JSR 308 还对类型声明的注释进行了改进，根据普遍同意，这些改进应该出现在 JSR 175 中。这些改进本身并不能证明或预测 JSR 308 中更广泛的更改，但出于同样的原因，如果没有 308 的“赞助”，这些改进是不可能发生的。）