空分析注释包之间有什么区别？

Question

我应该使用哪个@NotNull Java注释？这个问题已经过时了，而且有点基于观点。从那时起，Java 8和更新的IDE一起出现了。

虽然Java 8允许通过集成JSR 308来进行类型注释，但它没有附带任何注释。来自JSR 308解释:由Josh Juneau编写的Java类型注释

JSR 308是关于Java类型的注释，它被合并为Java 8的一部分。 ..。 可以编写编译器检查程序来验证带注释的代码，在代码不满足某些要求时通过生成编译器警告来强制执行规则。Java 8没有提供默认的类型检查框架，但是可以为类型检查编写自定义注释和处理器。还有许多类型检查框架可以下载，这些框架可以作为Java编译器的插件来检查和执行已注释过的类型。类型检查框架包括类型注释定义和一个或多个可插入模块，这些模块与编译器一起用于注释处理。

考虑到只提供某种@CanBeNull和@CannotBeNull的解决方案，我发现了以下信息(可能是错误的)：

• Eclipse的JDT空分析的org.eclipse.jdt.annotation。其他IDE有各自的软件包。使用JSR 308，而且仍然支持Java8之前的注释。
• FindBug的javax.annotation。使用休眠的JSR 305，它似乎没有使用Java8的类型注释。尽管它没有集成到Oracle中，但出于某种原因，它仍然使用javax域，这意味着它使用了javax域。
• 检查框架的org.checkerframework.checker.nullness.使用JSR 308。
• JavaEE的javax.validation.constraints。不知道它使用什么，但无论如何都没有@CanBeNull。

有些用于静态代码分析，有些用于运行时验证。

上述方案之间的实际区别是什么？是否有(将要制定)一个标准，还是每个人都要编写自己的分析框架？

Answer 1

除了前面提到的分析之外，还存在一些其他的空分析；例如，IntelliJ包含一个空度分析。

以下是关于无空分析的一些关键问题：

• 它是在编译时工作还是在运行时工作？编译时分析会给程序员预先警告潜在的错误。通过运行时分析，您的程序仍然会崩溃，但可能会更早崩溃，或者提供更多的信息错误信息。
• 它是一个验证者还是一个bug查找者？验证器提供了正确的保证:如果工具没有报告任何潜在的错误，那么程序将不会在运行时遭受给定的错误。bug查找器会报告一些问题，但是如果它没有报告任何问题，您的程序可能仍然是错误的。验证器通常需要程序员做更多的工作，包括对程序进行注释。一个bug查找器可能需要较少的努力才能开始使用，因为它可以运行在一个未加注释的程序上(尽管在这种情况下它可能不会给出很好的结果)。
• 分析有多精确？当程序实际上是正确的时候，它会经常遭受错误的警报，或者发出警告吗？它是否经常遭受误报，或者没有通知你程序中真正的错误？
• 工具是否内置于IDE中？如果是这样的话，它可能更容易使用。如果没有，它可以被任何程序员使用，而不仅仅是那些使用特定IDE的程序员。

您提到的三个工具都是在编译时工作的。FindBugs是一个bug查找器，其他是验证器。Checker具有更好的精度，但其他两个具有更好的IDE集成。FindBugs不适用于Java8类型注释(JSR 308)；其他两种注释都支持Java8和Java-8之前的注释。所有这些工具都有它们在程序员工具箱中的位置；哪个工具适合您，取决于您的需求和目标。

来回答你的其他问题：

FindBugs的注释使用javax域，因为它的设计者希望FindBugs作为一个Java标准(!)。从来没发生过。您是对的，javax的使用使许多人感到困惑，认为它是官方的或受甲骨文青睐的，但事实并非如此。

是否有(将要制定)一个标准，还是每个人都要编写自己的分析框架？

目前，Oracle希望社区能够尝试创建和使用各种分析框架。他们认为，他们还没有充分了解各种方法的利弊，无法创建一个标准。他们不想过早地创造一种标准来体现一种有缺陷的方法。他们愿意在未来制定一个标准。

Answer 2

你收集到的信息已经描述了这一点：

基于类型注释(JSR 308)的静态分析确实比以前的方法强大得多。

两组注释使用JSR 308，都是为了执行静态分析(也可以被认为是高级类型检查)。在核心部分，促进这些注释的两个工具本质上是兼容的(而且每个工具也可以使用另一个的注释)。据我所知，差异主要体现在两个方面：

• IDE一体化。
• 未注释类型的解释。在严格的中，每种类型要么是非空的，要么是可空的，因此如果缺少注释，默认情况下可以将其解释为非空。或者，底层类型系统可以使用“遗留类型”的概念，在需要“未经检查的转换”(类似于泛型类型和原始类型的组合)时发出警告。据我所知，Checkers应用了严格的方法，而Eclipse允许您在@NonNullByDefault策略和承认“遗留类型”(为了迁移)之间进行选择。

而且，据我所知，目前没有人打算投资于这些注释的标准化。