如何抑制有关已弃用 api 的 javac 警告？答案

【问题标题】：How can I suppress javac warnings about deprecated api?如何抑制有关已弃用 api 的 javac 警告？
【发布时间】：2010-12-05 23:42:32
【问题描述】：

当我编译时，javac 输出：

Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.`

我希望取消此警告。尝试 -Xlint:none 似乎没有帮助。

【问题讨论】：

为什么要避免呢？您应该使用不使用已弃用 API 的解决方案替换对已弃用 API 的调用。
因为我正在用许多行代码编译其他开发人员的模块。试图说服他们所有人检查代码并修复它是徒劳的。
为什么不让警告出现？这是一个很好的提醒，有些事情没有想象中的那么好
问题是“怎么做”，而不是“你认为我应该这样做吗？”。讨论“为什么”没有帮助。
我同意我们应该回答问题（“如何”）而不是质疑问题（“为什么？）。话虽如此，我会回答“为什么？”有时我们正在处理代码库使用已弃用的 API，我们无法控制它。如果我们的构建有 327 个关于弃用的警告，并且我们不小心引入了一个新的和真正的问题，那么第 328 个警告将不会被注意到。这就是为什么。

标签： java compiler-warnings javac

【解决方案1】：

根据我在文档中的信息，您无法在命令行上执行此操作。

根据javac documentation，-Xlint:none 仅禁用“Java 语言规范未强制要求”的警告。警告您使用已弃用的 API 似乎是由语言规范管理的。

您最好的选择是修复已弃用 API 的使用。但是，一个选项是将 @SuppressWarnings("deprecation") 注释添加到使用已弃用 API 的类或方法中。

【讨论】：

对于 Jdk 5，我使用 -Xlint:all 。这似乎抑制了所有关于弃用、未选中等的警告。
如果不推荐使用的类有导入怎么办？有没有隐藏此类警告的选项？
至少有一个合理的理由来禁止弃用警告，那就是当您的框架提供了一种已被弃用但框架本身在某些时候调用的方法，因为必须继续支持弃用的方法直到它被删除。

【解决方案2】：

两种可能的方式：

不要使用已弃用的 API
使用@SuppressWarnings("deprecation")

【讨论】：

1.不要使用已弃用的 API； 2. 在使用已弃用的 API 之前三思而后行； 3. 使用@SuppressWarnings("deprecation")。 :) +1
我问如何关闭警告。显然我可以避免使用已弃用的 API，但由于代码库涉及两个团队，我无法说服他们都这样做。
我们在使用 javac 的命令行中忽略了谁的编译警告？
我有一个梦想，有一天我可以无视警告而不会质疑我的动机。

【解决方案3】：

对于其他在谷歌搜索这个问题并像我一样偶然发现这个线程的人......

尝试： -Xlint:-弃用

它似乎在 JDK 6 上工作...不确定其他人。

【讨论】：

请记住，这不仅会禁用所选方法的所有弃用警告。
至少 icedtea8 的 javac 接受 -Xlint:-deprecation 只是为了忽略它。（即仍然会产生弃用警告。）
您可以同时使用多个 lint 设置。我的设置有-Xlint:all -Xlint:-deprecation，因此除弃用之外的所有内容都会生成警告。
我试过这个（使用 JDK7，Gradle 4.8.1），但仍然出现了烦人的Note:...。
这也适用于 java 11.0.6，但使用 "-Xlint:-deprecation" 和 "@SuppressWarnings("deprecation")" 是有区别的。使用 Xlint 方法会抑制警告，但您仍然会收到“注意 --- 使用或覆盖已弃用的 API”。这至少在 Eclipse/Ant 中也很烦人，因为它在控制台输出中以红色突出显示。

【解决方案4】：

在 Java 6 中，@Depreated 注释和编译器标志都不会在这里为您提供帮助。唯一对我有用的解决方案是在不推荐使用的方法上放置带有 @deprecated（小型大写字母）标记的 javadoc 注释：

/**
  * @deprecated overriding deprecated method
  */
@Override
public javax.xml.bind.Validator createValidator() throws JAXBException {...}

（该示例来自从 JAXBContext 派生的类。）

（我没有导入已弃用的 Validator 类以避免在 import 语句上出现警告。）

【讨论】：

谢谢沃尔夫冈。 @SuppressWarnings("deprecation") 注释没有完全工作，一些警告仍在输出。添加@deprecated 注释将它们全部抑制。

【解决方案5】：

使用 gradle 时，您可以轻松配置：

tasks.withType(JavaCompile) {
    options.deprecation = false
}

（使用 Gradle 2 和 Java 8 测试）

【讨论】：

注意：几年后，使用 gradle 6，这不再起作用。这几天对应的“isDeprecation”默认为false，不影响这个警告

【解决方案6】：

如果它是一个核心 Java API，那么几乎可以肯定有一个替代品可以满足您的需求。使用该额外参数运行 javac，然后查看已弃用方法的 API 并根据需要进行替换。

【讨论】：

使用哪个额外参数运行 javac？

【解决方案7】：

使用 nowarn 属性见下文

例如

<javac srcdir="src" 
  destdir="build/classes" source="1.6" 
  target="1.6" debug="true" encoding="Cp1252"
  nowarn="on">

默认情况下 nowarn 属性是关闭的

【讨论】：

其实错了。禁用警告不会阻止这些特定的“注释”出现。

【解决方案8】：

@SuppressWarnings("deprecation") 不适合我，而是我使用过

@SuppressWarnings("unchecked")

【讨论】：

【解决方案9】：

如果您在命令行中编译，您可以使用grep 过滤消息，只过滤掉包含不需要的内容的消息，例如grep -v deprecated。您可以使用| 将输出发送到grep，

your compile command | grep -v deprecated

【讨论】：

在这种情况下这真的不实用，尽管我很欣赏 Unix 管道的强大功能。许多工具不能很好地与 Unix Philosophy 配合使用。
我同意，这几乎没用。这非常简单：当你做自己的小项目时，这样的 grep -v 解决方案可能会起作用......在这样的设置中，你不会忽略警告，你会修复它们。在任何现实世界的项目中，如果你有太多警告，你想抑制它们，你就不需要手动编译。