Jak efektywniej korzystać z adnotacji @Nullable i @Nonnull?

Widzę to @Nullablei @Nonnulladnotacje mogą być pomocne w zapobieganiu NullPointerExceptions, ale nie rozprzestrzeniają się zbyt daleko.

• Skuteczność tych adnotacji spada całkowicie po jednym poziomie pośredniej, więc jeśli dodasz tylko kilka, nie będą one rozprzestrzeniać się zbyt daleko.
• Ponieważ te adnotacje nie są dobrze egzekwowane, istnieje niebezpieczeństwo, że wartość oznaczona znakiem @Nonnullnie jest zerowa, a co za tym idzie, nie będzie przeprowadzać kontroli zerowej.

Poniższy kod powoduje, że parametr oznaczony symbolem @Nonnulljest nullbez zgłaszania zastrzeżeń. Rzuca, NullPointerExceptiongdy jest uruchomiony.

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

Czy istnieje sposób na bardziej rygorystyczne egzekwowanie i / lub dalsze rozpowszechnianie tych adnotacji?

Krótka odpowiedź: myślę, że te adnotacje są przydatne tylko dla twojego IDE, aby ostrzec cię o potencjalnie zerowych błędach wskaźnika.

Jak powiedziano w książce „Wyczyść kod”, powinieneś sprawdzić parametry swojej metody publicznej, a także unikać sprawdzania niezmienników.

Kolejną dobrą wskazówką jest to, że nigdy nie zwraca wartości null, ale zamiast tego używa się wzorca obiektu Null .

Poza tym, że IDE daje wskazówki, gdy przechodzisz nulldo metod, które oczekują, że argument nie będzie zerowy, istnieją dalsze zalety:

• Narzędzia do statycznej analizy kodu mogą testować to samo, co IDE (np. FindBugs)
• Możesz użyć AOP, aby sprawdzić te potwierdzenia

Dzięki temu Twój kod będzie łatwiejszy w utrzymaniu (ponieważ nie potrzebujesz nullsprawdzania) i mniej podatny na błędy.

Myślę, że to oryginalne pytanie pośrednio wskazuje na ogólne zalecenie, że sprawdzanie wskaźnika zerowego w czasie wykonywania jest nadal potrzebne, mimo że używane jest @NonNull. Skorzystaj z następującego łącza:

Nowe adnotacje typu Java 8

W powyższym blogu zaleca się:

Opcjonalne adnotacje typu nie zastępują sprawdzania poprawności w czasie wykonywania. Przed adnotacjami typu podstawową lokalizacją do opisywania takich elementów, jak wartość null lub zakresy, był plik javadoc. W przypadku adnotacji typu ta komunikacja jest przekazywana do kodu bajtowego w sposób umożliwiający weryfikację w czasie kompilacji. Twój kod powinien nadal przeprowadzać walidację w czasie wykonywania.

Kompilując oryginalny przykład w Eclipse przy zgodności 1.8 i z włączoną analizą null opartą na adnotacjach, otrzymujemy następujące ostrzeżenie:

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

To ostrzeżenie jest sformułowane analogicznie do tych ostrzeżeń, które pojawiają się podczas mieszania wygenerowanego kodu ze starszym kodem przy użyciu typów surowych („konwersja niesprawdzona”). Tutaj mamy dokładnie taką samą sytuację: metoda indirectPathToA()ma "legacy" podpis, ponieważ nie określa żadnego zerowego kontraktu. Narzędzia mogą z łatwością to zgłosić, więc będą ścigać Cię po wszystkich zaułkach, w których należy propagować adnotacje o wartości NULL, ale jeszcze nie jest.

A kiedy używamy sprytnego @NonNullByDefault, nie musimy nawet tego mówić za każdym razem.

Innymi słowy: to, czy adnotacje o wartości zerowej „rozprzestrzeniają się bardzo daleko”, może zależeć od używanego narzędzia i od tego, jak rygorystycznie przestrzegasz wszystkich ostrzeżeń wysyłanych przez to narzędzie. Dzięki adnotacjom o wartości NULL TYPE_USE możesz wreszcie pozwolić narzędziu ostrzec Cię o każdym możliwym NPE w programie, ponieważ wartość zerowa stała się nieodłączną właściwością systemu typów.

Zgadzam się, że adnotacje „nie rozprzestrzeniają się zbyt daleko”. Widzę jednak błąd po stronie programisty.

NonnullAdnotację rozumiem jako dokumentację. Poniższa metoda wyraża, że ​​wymaga (jako warunku wstępnego) argumentu innego niż null x.

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

Poniższy fragment kodu zawiera błąd. Metoda wywołuje directPathToA()bez wymuszania, że yjest różna od null (to znaczy nie gwarantuje warunku wstępnego wywoływanej metody). Jedną z możliwości jest dodanie Nonnulladnotacji również do indirectPathToA()(propagowanie warunku wstępnego). Możliwość druga polega na sprawdzeniu nieważności yin indirectPathToA()i uniknięciu wywołania directPathToA()kiedy yjest zerowe.

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

To, co robię w moich projektach, to aktywowanie następującej opcji podczas inspekcji kodu „Stałe warunki i wyjątki”:
Zaproponuj adnotację @Nullable dla metod, które mogą zwracać wartość null i zgłaszać wartości null przekazywane do parametrów bez adnotacji

Po aktywacji wszystkie parametry bez adnotacji będą traktowane jako niezerowe, a zatem zobaczysz również ostrzeżenie dotyczące połączenia pośredniego:

clazz.indirectPathToA(null); 

Dla jeszcze silniejszych testów dobrym wyborem może być Checker Framework (zobacz ten fajny samouczek .
Uwaga : jeszcze go nie używałem i mogą wystąpić problemy z kompilatorem Jacka: zobacz ten raport o błędzie

W Javie użyłbym opcjonalnego typu Guava . Będąc rzeczywistym typem, kompilator gwarantuje jego użycie. Łatwo go ominąć i uzyskać NullPointerException, ale przynajmniej podpis metody jasno komunikuje, czego oczekuje jako argument lub co może zwrócić.

Jeśli używasz Kotlin, obsługuje on te adnotacje o wartości zerowej w swoim kompilatorze i zapobiega przekazywaniu wartości null do metody Java, która wymaga argumentu innego niż null. Chociaż to pytanie było pierwotnie skierowane do Javy, wspominam o tej funkcji Kotlin, ponieważ jest ona specjalnie ukierunkowana na te adnotacje Java, a pytanie brzmiało: „Czy istnieje sposób, aby te adnotacje były bardziej rygorystycznie egzekwowane i / lub dalej rozpowszechniane?” i ta funkcja sprawia, że ​​te adnotacje są bardziej rygorystyczne .

Klasa Java za pomocą @NotNulladnotacji

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

Klasa Kotlin wywołująca klasę Javy i przekazująca wartość null dla argumentu z adnotacją @NotNull

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

Błąd kompilatora Kotlin wymuszający @NotNulladnotację.

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

zobacz: http://kotlinlang.org/docs/reference/java-interop.html#nullability-annotations

Ponieważ nowa funkcja Java 8 jest opcjonalna , nie należy już używać @Nullable ani @Notnull we własnym kodzie . Weźmy poniższy przykład:

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

Można go przepisać za pomocą:

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

Użycie opcjonalnego wymusza sprawdzenie wartości null . W powyższym kodzie dostęp do wartości można uzyskać tylko przez wywołanie getmetody.

Kolejną zaletą jest to, że kod staje się bardziej czytelny . Po dodaniu Java 9 ifPresentOrElse funkcję można by nawet zapisać jako:

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