我见过很多例子使用DeprecatedAPI 上的注释以便将它们标记为“需要尽快更换”。

然而，在几乎所有这些情况下，代码开发人员不仅继续使用已弃用的 API，而且还继续使用已弃用的 API。抑制了弃用警告.

API 开发人员的最佳意图似乎最终会创建更多与已实现的业务逻辑无关的代码 - 如果 API 已被弃用，但在相关警告被抑制的情况下继续使用，那么充其量似乎是代码的退化，并且恕我直言，在最坏的情况下替换已弃用的库时可能是一个潜在的应用程序断点。

这个问题有实际的解决办法吗？至少，如果这种情况确实在 CR 中停留了相对较长的时间，那么有一种方法可以将这种情况标记为代码异味吗？

请建议您可能正在使用的实际解决方案（库、SCA、CR 插件等......）

是否有任何计划中的 JRE/JDK 功能可以帮助解决这种情况？我的研究目前还没有发现任何东西。

参考：

• 在java中注释已弃用的类的最佳方法是什么
• 使用已弃用的 api 是否错误
• 使用 @SuppressWarnings 排除警告
• 使用 @Deprecated Java 类而不产生编译警告

第 1 步：宣布删除

人们可能认为弃用 API 意味着宣布它将被删除，但这并不是唯一的用例（如相关文章中所述，例如Java 7 and Java 9):

• 该 API 是危险的（例如，Thread.stop方法）。

• 有一个简单的重命名（例如，AWTComponent.show/hide取而代之setVisible).

• 可以使用更新、更好的 API 来代替。

• 已弃用的 API 将被删除。

更复杂的是，在 Java 9 之前，JDK 中没有删除任何已弃用的 API（请参阅Java 弃用 20 年），因此如果开发人员不认真对待弃用（无论是在 JDK 还是其他地方），这是可以理解的。

因此，您需要清楚地传达 API真的真的会被移除。执行此操作的方法取决于编译 API 所使用的 Java 版本。

Java 8 或更低版本

在这些 Java 版本中，没有正式的方法来明确区分各种弃用用例。您能做的最好的事情就是添加 Javadoc 标签@deprecated不仅给出弃用的原因并列出替代方案，还明确宣布您打算删除该 API。

Java 9 或更高版本

从 Java 9 开始，增强弃用，你现在可以写

@Deprecated(forRemoval=<boolean>)

明确记录您的意图。我认为与 Javadoc 一起@deprecated（其中应详细说明弃用的原因并列出替代方案），这个标准化标志是一个公平的警告。

将此标志设置为true，编译器将针对每次使用已弃用的元素发出警告，如下所示：

YourClass.java:<line>: warning: [removal] <method> in <class> has been
deprecated and marked for removal

默认情况下启用此警告（而不必使用-Xlint:deprecation） 并且是not抑制与@SuppressWarnings("deprecation")。相反，人们必须用新的方法来抑制它@SuppressWarnings("removal")，这可能会让开发人员在没有充分理由的情况下三思而后行。

此外，您可以明确声明引入弃用的库版本

@Deprecated(since="<version>")

在 Javadoc 或源代码中查看这一点可以帮助开发人员评估更新代码的紧迫性。

步骤 2a：运行时警告

如果这种情况可行，请添加运行时提醒：当使用已弃用的 API 时，让它在控制台或日志文件（使用您使用的任何日志记录机制）中记录一条警告，宣布这将不再适用于下一个主要版本。为了避免垃圾邮件，您只能记录一次（例如private static boolean warningLogged).

步骤2b：静态代码分析

静态代码分析器如声纳Qube（也可作为托管服务) 可以设置为标记每个警告。 SonarQube 规则“不应使用已弃用的代码”如果编译器的弃用使用警告被抑制，甚至应该可以工作。

SonarQube 还跟踪某个问题（即违反规则）的引入时间（基于版本控制），您可以根据该日期交互式地过滤其问题列表。例如，您可以列出已在代码库中存在一年多的已弃用代码的所有用法，以便您可以优先考虑修复它们的工作。

第 3 步：删除 API

不实际删除 API 会给 API 用户留下他们不需要费心更改代码的印象。