当@SuppressWarnings（“deprecation”）不起作用时，如何避免弃用警告？

我们有一个Java项目。我们为 启用 （启用警告） 和 （将警告视为错误） 标志，以确保我们的代码没有警告。最近，我们决定弃用一个类。问题是在某些情况下根本不会禁止使用警告，从而导致构建失败。以下是我遇到的用例列表：-Xlint-Werrorjavac@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，将其保留在代码库中，等待所有客户端迁移，然后将其删除。有三种常见的用例：

• 我们弃用类 和 ，其中 extends .这就是我的问题中的情况2和3。FooBarFooBar
• 我们弃用类 和 ，其中 extends .这是情况 2 和 4。FooBarFooCollection<Bar>
• 我们必须保留类 和 的所有测试代码。测试代码导入这些类。情况如下 1.FooBar

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

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