JEP 104: Type Annotations | 类型注解

原文

摘要

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

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

标准化可插拔类型检查器。

使用类似 Ernst 的“Checker Framework”等框架构建的三个重要的可插拔类型检查器，基于 Java SE 8。
可能将至少一种注解方案（例如，用于控制空值）应用于 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 进行了有针对性的更改，以便可以检索特定类型名称实例上的注解。

可以使用诸如 FindBugs 之类的工具评估习惯用法的编译时软件质量，而无需程序员提供的注解。
可以在类型名称旁边使用类似于 /* */ 的注释，表明可以放置注解，从而将“注解”从语言本身中“隐藏”起来。这增加了视觉混乱，并且仍然需要进行类文件和反射更改。

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

风险：广大的 Java 开发社区对开发或使用可插拔类型系统不感兴趣。
假设：可插拔类型检查的效用值得对 Java 的语法、类文件和 API 进行重大更改。（除了对类型使用的注解外，JSR 308 还改进了对类型声明的注解，根据共识，这些改进应该在 JSR 175 中发生。这些改进本身并不能证明或预测 JSR 308 的更广泛的变化，但同样地，如果没有 308 的“支持”，这些改进不太可能发生。）