Java弃用的API和抑制警告“弃用”-实用方法

Question

我看到了许多在API上使用弃用注释的示例，以便将它们标记为“需要尽快更换”。

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

API开发人员的最佳意图似乎最终会创建更多与已实现的业务逻辑无关的代码——如果API已弃用但不断使用并抑制相关警告，则看起来充其量是代码的退化，并且在最坏的情况下替换弃用的库时是潜在的应用程序断点IMHO。

这个问题有没有切实可行的解决办法？如果它确实在CR中停留了相对较长的时间，那么至少有一种方法可以将此事件标记为代码气味？

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

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

参考文献：

• 在java中注释已弃用类的最佳方法是什么
• 使用不推荐的api是否错误
• 使用@SuppressWarnings排除警告
• 在没有编译警告的情况下使用@弃用的Java类

Answer 1

这个问题有实际的解决方案吗？

从谁的角度来看是实用的？

从经常忽略/抑制不推荐警告的开发人员的角度来看，他们已经有了自己的“解决方案”。。。这就是忽视问题。但另一方面，其他人无法阻止他们这样做。但另一面的另一面是。。。最终这与其他人无关。

从希望不推荐他们维护的API的开发人员的角度来看，他们已经有了一个解决方案。想做就做然后继续执行下一步，实际删除不推荐使用的API。另一方面，它会惹恼一些人，而其他人会被烧死。（尤其是那些经常忽视/压制反对警告的人。但请参见上文：这是他们的问题。）

从关注/负责维护组织代码库的代码质量/完整性的人的角度来看，是的，存在一个问题。但解决方案相对来说是狭隘的：

• 禁止代码使用@抑制（“弃用”）'。
• 禁止关闭弃用警告的构建脚本。
• 通过SCI服务器插件、自定义样式检查器规则或（如果您想粗鲁）通过“greping”源代码来强制执行上述内容。
• 对屡犯的程序员采取（隐喻性的）大棒。

是否有任何计划中的JRE/JDK特性可以帮助解决这种情况？

如前所述，Java 9增强了注释支持（请参见JEP 277）：

• 提供了更多信息的弃用标记，并且
• 提供了一个工具（jdeprscan），用于扫描针对JavaSE API的弃用违规行为。

Answer 2

不推荐使用的API仅在使用不推荐使用的API进行注释时才有用。如果API客户机在多年被标记为不推荐使用后仍然可以成功使用它，那么可以说API提供程序没有以任何实际方式帮助他们。

这个问题有没有切实可行的解决办法？

是：让弃用表示弃用，如果删除是正确的处理方法，则在宽限期后，使弃用的API不可用。例如，如果您不赞成存在安全风险的API，那么在将来的版本中不删除它会使不赞成变得无用，并可能被视为导致问题的原因。

不推荐使用的注释只不过是文档，正如您所指出的，其他开发人员可以忽略它。

Java9弃用可能信息更丰富，但最终决定仍然取决于使用API的开发人员，这并不能解决问题。

Answer 3

人们可能认为弃用API意味着宣布它将被删除，但这不是唯一的用例（如Java7和Java9的相关文章所述）：

>

有一个简单的重命名（例如，AWT组件。显示/隐藏被设置可见替换）。

可以使用更新、更好的API。

已弃用的API将被删除。

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

因此，您需要清楚地表明，API真的、真的将被删除。实现这一点的方法取决于编译API时使用的Java版本。

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

自Java 9以来，通过增强的弃用功能，您现在可以编写

@Deprecated(forRemoval=<boolean>)

明确记录您的意图。我认为，与Javadoc（应该详细说明不推荐的原因并列出备选方案）一起，这个标准化标志是一个合理的警告。

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

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

默认情况下，此警告处于启用状态（而不必使用Xlint:deprecation启用），并且不会使用SuppressWarnings（“deprecation”）抑制此警告。相反，必须使用新的SuppressWarnings（“removation”）来抑制它，这可能会让开发人员在没有真正好的理由的情况下三思而后行。

此外，您还可以显式地说明使用

@Deprecated(since="<version>")

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

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

可以设置像SonarQube（也可作为托管服务提供）这样的静态代码分析器来标记这些警告中的每一个。如果编译器的弃用使用警告被抑制，SonarQube规则“不应使用已弃用的代码”甚至应该有效。

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

不实际删除API会给您的API用户留下这样的印象，即他们不需要费心修改代码。