当@SuppressWarnings("deprecation") 不起作用时如何避免弃用警告？

Question

我们有一个 Java 项目。我们为javac 启用-Xlint（启用警告）和-Werror（将警告视为错误）标志，以确保我们的代码没有警告。最近我们决定弃用一个类。问题是在某些情况下@SuppressWarnings("deprecation") 根本不会抑制弃用警告，从而导致构建失败。以下是我遇到的用例列表：

1. 在其他未弃用的类中导入。
2. 在其他已弃用的类中导入。
3. 父类。

4. 类型参数。例如

   @SuppressWarnings("deprecation")
   public class Foo extends Bar<DeprecatedClass>
   { ... }
   

   但是，即使没有抑制，这个也没有警告：

   @Deprecated
   public class DeprecatedClass extends Bar<DeprecatedClass>
   { ... }
   

AFAIK，没有注释导入的语法，所以对于情况 1 和 2，我们的解决方案是导入 * 或避免导入。对于案例 3 和 4，Java 6 和 7 都不会抑制警告。 Java 8 将正确地抑制它（也许修复了一个错误）。到目前为止还没有解决方案。

不幸的是，我们现在必须支持 Java 6、7 和 8。有没有办法解决这个问题？这是我们 Java API 发展的障碍。

附录

很多人问为什么我们仍然在我们自己的代码库中使用已弃用的类。原因是该项目是一个库，支持许多不同的客户端。在引入新的替代 API 时，我们必须首先弃用旧 API，将其保留在我们的代码库中，等待所有客户端迁移然后将其删除。常见的用例有以下三种：

• 我们弃用了 Foo 和 Bar 类，其中 Foo 扩展了 Bar。这是我的问题中的情况 2 和 3。
• 我们弃用了 Foo 和 Bar 类，其中 Foo 扩展了 Collection<Bar>。这是案例 2 和 4。
• 我们必须保留类Foo 和Bar 的所有测试代码。测试代码导入这些类。情况 1 是这样。

为什么要保留测试？不要忘记，如果发现了严重的错误（例如内存泄漏、安全问题），并且客户端无法轻松迁移到新版本，我们仍然需要对旧 API 进行错误修复。所有更改都必须经过测试。

我觉得我们的情况在软件库开发和 API 演进中应该相当普遍。令人惊讶的是，Java 花了这么长时间（直到 Java 8）来修复这个错误。

Answer 1

通常，当您弃用类时，您不希望任何人在以后的版本中使用它。此外，您的代码库也应该停止使用已弃用的类。当你说每个人都不要使用 MySuperDeprecatedUtil 类但继续在你的代码库中使用它时，这看起来很奇怪。

如果您需要在其他类中使用 MySuperDeprecatedUtil 类 - 您应该将使用它的类标记为 @Deprecated - 每个使用过时代码的类都应该被弃用，或者会产生编译警告，或者应该被删除，或者应该停止使用已弃用的代码。

如果您不能停止使用您的课程 - 也许现在弃用它还为时过早？

在我的实践中，当我想弃用某个类时，我会创建替换类，例如MySuperFreshUtil。尽可能将所有使用 MySuperDeprecatedUtil 的类切换到 MySuperFresh util 保留接口（如果不可能 - 使用 FQCN 并将方法标记为已弃用）。将 MySuperDeprecatedUtil 标记为 @Deprecated 并添加注释应该使用哪个类以及如何使用。然后我在单个更改列表中提交这些更改。

Answer 2

考虑使用 -Xmaxwarns，您可以控制停止前的警告次数。

或者尝试收集警告的数量并失败集成过程，而不是编译。

例如：https://issues.apache.org/jira/browse/HADOOP-11252。 提交到 hadoop 项目的每个代码都需要通过自动化 CI，它会给出 -1 以增加警告的数量。

Answer 3

很抱歉，我没有解决您面临的问题的方法，但正如您所观察到的，已经取得了一些进展。我们一直在尝试消除 JDK 本身中的所有 Java 编译警告，这是一个漫长而艰难的过程。在 2011 年的 JDK 8 开发过程中，我帮助了 kick off the warnings cleanup effort 和后来的 co-presented a JavaOne talk (slides and audio)。

最近，我的同事 Joe Darcy 继续进行警告清理工作，并处理了不同的警告类别，并拥有finally reached deprecation warnings。正如您所指出的，编译器在处理抑制弃用警告时存在一些错误，例如在 JDK 8 中修复的JDK-6480588。不幸的是，在 JDK 8 中仍然无法抑制对已弃用项目的导入的警告。这个错误，JDK-8032211，是最近在我们的 JDK 9 开发线中修复的。事实上，我们仍在调整@Deprecated 注释的处理。例如，错误JDK-6481080 阐明了尝试在package-info.java 文件中使用@Deprecated 实际上并不会弃用该包；这个错误是在上周修复的。还有more work to be done，但在这一点上有点投机。

JDK 面临与您类似的问题，因为我们必须为仍在使用它们的客户端维护已弃用的 API。但是由于我们在内部使用和实现了这样的 API，我们有很多弃用警告要压制。在撰写本文时，在我们的 JDK 9 开发线中，我们仍然无法在没有弃用警告的情况下编译系统。因此，lint 警告的javac 选项仍然是：

-Xlint:all,-deprecation

您可能还必须在编译中禁用弃用警告，尤其是在您仍在 JDK 6 上构建的情况下。我目前还没有解决办法。

关于您的一个弃用案例的最后一点：

@Deprecated
public class DeprecatedClass extends Bar<DeprecatedClass> { ... }

这不会发出弃用警告，也不应该发出。 Java Language Specification, section 9.6.4.6 指定如果在本身已被弃用的实体中使用已弃用的实体，则不会发出弃用警告。