如何更有效地使用@Nullable和@Nonnull注释？

我可以看到@Nullable和@Nonnull注释可能有助于防止NullPointerExceptions，但它们不会传播太远。

• 这些注释的有效性在一个间接级别之后会完全下降，因此，如果仅添加一些注释，它们的传播就不会太远。
• 由于这些注释的执行不正确，因此存在以下危险：假定标有的值@Nonnull不为空，因此不执行空值检查。

以下代码使标记@Nonnull为的参数null不会引起任何投诉。它NullPointerException在运行时抛出一个。

public class Clazz {
    public static void main(String[] args){
        Clazz clazz = new Clazz();

        // this line raises a complaint with the IDE (IntelliJ 11)
        clazz.directPathToA(null);

        // this line does not
        clazz.indirectPathToA(null); 
    }

    public void indirectPathToA(Integer y){
        directPathToA(y);
    }

    public void directPathToA(@Nonnull Integer x){
        x.toString(); // do stuff to x        
    }
}

有没有办法使这些注释更严格地执行和/或进一步传播？

简短的答案：我想这些注释仅对您的IDE有用，可以警告您潜在的空指针错误。

如《清洁代码》一书中所述，您应检查公共方法的参数，并避免检查不变量。

另一个好技巧是永远不要返回空值，而应使用空对象模式。

除了在传递null给期望参数不为null的方法时为您提供提示的IDE之外，还有其他优点：

• 静态代码分析工具可以测试与您的IDE相同的工具（例如FindBugs）
• 您可以使用AOP检查这些断言

这可以帮助您的代码更具可维护性（因为您不需要null检查），并且不易出错。

我认为这个原始问题间接指向一个普遍的建议，即使使用@NonNull，仍然需要运行时空指针检查。请参考以下链接：

Java 8的新类型注释

在以上博客中，建议：

可选的类型注释不能替代运行时验证 在类型注释之前，用于描述可空性或范围之类的内容的主要位置位于javadoc中。通过类型注释，此通信以一种编译时验证的方式进入字节码。您的代码仍应执行运行时验证。

在Compliance 1.8上的Eclipse中编译原始示例并启用基于注释的空分析，我们得到以下警告：

    directPathToA(y);
                  ^
Null type safety (type annotations): The expression of type 'Integer' needs unchecked conversion to conform to '@NonNull Integer'

该警告的措辞类似于使用原始类型将生成的代码与遗留代码混合时收到的那些警告（“未经检查的转换”）。这里的情况完全相同：方法indirectPathToA()具有“旧版”签名，因为它没有指定任何空合同。工具可以轻松地报告此情况，因此，它们会在需要传播但尚未传播空注释的所有小巷中向您追赶。

而且当使用聪明的时候，@NonNullByDefault我们甚至不必每次都说这个。

换句话说：空注释是否“传播得很远”可能取决于您使用的工具，以及您对工具发出的所有警告的重视程度。随着TYPE_USE空注解你终于有让工具警告你选择每一个在你的程序可能NPE，因为NULL的含量已成为类型系统的intrisic财产。

我同意注释“不会传播得太远”。但是，我看到了程序员方面的错误。

我将Nonnull注释理解为文档。以下方法表示需要（作为前提）一个非null参数x。

    public void directPathToA(@Nonnull Integer x){
        x.toString(); // do stuff to x        
    }

以下代码段包含一个错误。该方法在directPathToA()不强制y为非null的情况下进行调用（也就是说，它不保证所调用方法的先决条件）。一种可能性是也要添加Nonnull注释indirectPathToA()（传播先决条件）。可能性二是检查yin 的无效性，indirectPathToA()并避免调用directPathToA()when y为null。

    public void indirectPathToA(Integer y){
        directPathToA(y);
    }

我在项目中所做的是在“恒定条件与异常”代码检查中激活以下选项：
建议@Nullable批注用于可能返回空值并报告传递给非批注参数的可空值的方法

激活后，所有未注释的参数将被视为非空，因此您还将在间接调用中看到警告：

clazz.indirectPathToA(null); 

对于更强大的检查，Checker Framework可能是一个不错的选择（请参阅此教程。
注意：我还没有使用过，并且Jack编译器可能存在问题：请参见此bugreport

在Java中，我将使用Guava的Optional类型。作为实际类型，您可以得到编译器的保证。绕过它并获得很容易NullPointerException，但是至少方法的签名清楚地传达了期望作为参数或可能返回的内容。

如果您使用Kotlin，它将在其编译器中支持这些可为空性注释，并且将阻止您将null传递给需要非null参数的java方法。事件虽然此问题最初是针对Java的，但我提到Kotlin功能是因为它专门针对这些Java注释，而问题是“是否有一种方法可以使这些注释更严格地实施和/或进一步传播？” 并且此功能确实使这些注释的执行更加严格。

使用@NotNull注解的Java类

public class MyJavaClazz {
    public void foo(@NotNull String myString) {
        // will result in an NPE if myString is null
        myString.hashCode();
    }
}

Kotlin类调用Java类，并为用@NotNull注释的参数传递null

class MyKotlinClazz {
    fun foo() {
        MyJavaClazz().foo(null)
    }
}  

Kotlin编译器执行@NotNull注释时出错。

Error:(5, 27) Kotlin: Null can not be a value of a non-null type String

参见：http : //kotlinlang.org/docs/reference/java-interop.html#nullability-annotations

由于Java 8的新功能Optional，您不应再在自己的代码中使用@Nullable或@Notnull。请看下面的例子：

public void printValue(@Nullable myValue) {
    if (myValue != null) {
        System.out.print(myValue);
    } else {
        System.out.print("I dont have a value");
}

可以用以下代码重写：

public void printValue(Optional<String> myValue) {
    if (myValue.ifPresent) {
        System.out.print(myValue.get());
    } else {
        System.out.print("I dont have a value");
}

使用可选选项会强制您检查是否为空值。在上面的代码中，您只能通过调用get方法来访问值。

另一个优点是代码更具可读性。通过添加Java 9 ifPresentOrElse，该函数甚至可以编写为：

public void printValue(Optional<String> myValue) {
    myValue.ifPresentOrElse(
        v -> System.out.print(v),
        () -> System.out.print("I dont have a value"),
    )
}