jdk170不支持注释_JDK 9 @不建议使用的注释增强功能

jdk170不支持注释

在帖子中， @ 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早期版本要好得多，因为我们现在可以在批注本身内指定弃用的两个非常重要的特征。指定何时不建议使用构造以及何时计划完全删除它，可以提供与不赞成使用有关的具有潜在洞察力的历史和未来信息。