@Nullableおよび@Nonnullアノテーションをより効果的に使用するにはどうすればよいですか？

私はそれを見ることができる@Nullableと@Nonnull注釈ができ予防に有用であるNullPointerExceptionのを、彼らは非常に遠くに伝播されません。

• これらの注釈の有効性は、1レベルの間接参照の後に完全に低下するため、ほんの数個追加しただけでは、あまり伝播しません。
• これらの注釈は十分に実施されていないため、でマークされた値@Nonnullがnull ではないと想定し、その結果nullチェックを実行しない危険があります。

以下のコードはでマークされたパラメータが発生@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値を返すことはありませんが、代わりにnullオブジェクトパターンを使用することです。

null引数がnullでないことを期待するメソッドに渡すときにヒントを提供するIDE以外に、次のような利点があります。

• 静的コード分析ツールはIDEと同じようにテストできます（例：FindBugs）
• AOPを使用してこれらのアサーションを確認できます

これにより、コードの保守性が向上し（nullチェックが不要になるため）、エラーが発生しにくくなります。

この元の質問は、@ NonNullが使用されていても、実行時のnullポインターチェックが引き続き必要であるという一般的な推奨事項を間接的に指摘していると思います。次のリンクを参照してください。

Java 8の新しい型注釈

上記のブログでは、次のことをお勧めします。

オプションの型注釈はランタイム検証の代わりにはなりません。型注釈の 前は、null可能性や範囲などを記述するための主要な場所はjavadocでした。Typeアノテーションを使用すると、この通信はコンパイル時の検証方法でバイトコードに入ります。コードは引き続きランタイム検証を実行する必要があります。

Eclipseでコンプライアンス1.8の元の例をコンパイルし、アノテーションベースのnull分析を有効にすると、次の警告が表示されます。

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

この警告は、生成されたコードを生の型を使用してレガシーコードと混合するときに発生する警告（ "チェックされていない変換"）と同様に表現されています。ここでもまったく同じ状況です。メソッドindirectPathToA()には「レガシー」シグネチャがあり、nullコントラクトを指定していません。ツールはこれを簡単に報告できるので、nullアノテーションを伝播する必要があるが、まだ伝播されていないすべての路地を追いかけます。

そして、賢いもの@NonNullByDefaultを使うとき、毎回これを言う必要すらありません。

言い換えると、nullアノテーションが「遠くまで伝播する」かどうかは、使用するツール、およびツールによって発行されたすべての警告にどれほど厳密に対応するかに依存します。TYPE_USEヌル注釈あなたは最終的にツールがについて警告聞かせするオプションが持っているすべての nullであるかどうかは、型システムのintrisic財産となっていますので、あなたのプログラムで可能なNPEを。

注釈は「あまり遠くまで伝播しない」ことに同意します。しかし、プログラマー側には間違いがあるようです。

Nonnull注釈をドキュメントとして理解しています。次のメソッドは、（前提条件として）null以外の引数が必要であることを表していますx。

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

次のコードスニペットにはバグが含まれています。メソッドは、それがnullでdirectPathToA()ないことを強制せずに呼び出しyます（つまり、呼び出されたメソッドの前提条件は保証されません）。1つの可能性は、（前提条件の伝播）にNonnullも注釈を追加することindirectPathToA()です。可能性2は、yin がnull かどうかを確認し、when がnullの場合indirectPathToA()の呼び出しを回避することです。directPathToA()y

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

私のプロジェクトで行うことは、「定数条件と例外」コードインスペクションで次のオプションをアクティブ
にすることです。nullを返す可能性のあるメソッドに@Nullableアノテーションを提案し、アノテーションなしのパラメーターに渡されたnull可能値を報告する

有効にすると、すべての非注釈付きパラメーターが非nullとして扱われるため、間接呼び出しに関する警告も表示されます。

clazz.indirectPathToA(null); 

さらに強力なチェックを行うには、Checker Frameworkを選択することをお勧めします（この素晴らしいチュートリアルを参照してください。
注：まだ使用していないため、Jackコンパイラに問題がある可能性があります。このバグレポートを参照してください）

Javaでは、GuavaのOptionalタイプを使用します。実際の型であるため、コンパイラはその使用について保証します。これをバイパスしてを取得するのは簡単ですNullPointerExceptionが、少なくともメソッドのシグネチャは、引数として期待されるもの、またはメソッドが返すものを明確に伝えます。

Kotlinを使用する場合、コンパイラでこれらのnull可能性アノテーションがサポートされ、null以外の引数を必要とするjavaメソッドにnullを渡すことができなくなります。この質問は元々Javaを対象としたものでしたが、これらのJavaアノテーションを特に対象としているため、このKotlin機能について言及しました。「これらのアノテーションをより厳密に適用および/またはさらに伝播させる方法はありますか？」この機能により、これらの注釈がより厳密に適用されます。

@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)
    }
}  

@NotNullアノテーションを強制するKotlinコンパイラエラー。

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の新機能はオプションであるため、独自のコードで@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");
}

オプションを使用すると、null値をチェックする必要があります。上記のコードでは、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"),
    )
}