JDK 9 @不建议使用的注释增强功能

在帖子中， @ Deprecated可能会是什么样子？，我当时使用JEP 277 （“增强的弃用”）的描述来指导创建增强的自定义@Deprecated注释。但是，自从发布该文章以来，JEP 277进行了重大更改。该文章总结了JDK 9的更改以及@Deprecated的当前计划的增强功能。

在2016-03-03 18:04对JDK-8065614 （“ JEP 277：增强的弃用”）所做的更改删除了JEP描述中描述拟议的@Deprecated枚举的部分。 JEP 277主页上的“ 替代方法 ”部分介绍了为何删除枚举的原因：

该提案的先前版本包含各种“原因”代码，包括未审查，危险，过时，已取代，未完成和实验。 这些尝试尝试编码不推荐使用API的原因，使用它的风险以及是否有可用的替代API。 实际上，所有这些信息都过于主观，无法在注释中编码为值。 而是应在Javadoc文档注释中描述此信息。

修改后的@Deprecated注释现在支持两种方法，如API文档中所示。该文档解释说， forRemoval（）方法 “指示可评估的元素是否在将来的版本中会被删除”，并且默认情况下返回false 。 since（）方法文档指出，第二个方法“返回已弃用带注释元素的版本”，并且默认情况下返回空字符串。

forRemoval()和since()的默认值false和""分别是有意义的，因为这些默认值对应于今天无法使用@Deprecated指定此信息。因为在代码库中已经有@Deprecated无数用法，所以使@Deprecated这些现有用法对应于没有计划的删除和没有指定的“自”是最有意义的。开发人员将能够根据需要将这些值添加到现有@Deprecated批注中。

这些是@Deprecated批注的次要添加，但是新的@Deprecated仍然比我们在Java早期版本中的今天要好得多，因为我们现在可以在批注本身中指定弃用的两个非常重要的特征。指定何时不建议使用构造以及何时计划完全删除它，可以提供与不赞成使用有关的具有潜在洞察力的历史和未来信息。