Come utilizzare le annotazioni @Nullable e @Nonnull in modo più efficace?

Vedo che @Nullablee le @Nonnullannotazioni potrebbero essere utili per prevenire NullPointerExceptions ma non si propagano molto lontano.

• L'efficacia di queste annotazioni diminuisce completamente dopo un livello di riferimento indiretto, quindi se ne aggiungi solo alcune non si propagano molto lontano.
• Poiché queste annotazioni non vengono applicate correttamente, esiste il pericolo di presumere che un valore contrassegnato @Nonnullnon sia null e di conseguenza non eseguire controlli null.

Il codice seguente fa sì che un parametro contrassegnato con @Nonnullsia nullsenza sollevare lamentele. Emette un NullPointerExceptionquando viene eseguito.

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

C'è un modo per rendere queste annotazioni più rigorosamente applicate e / o propagare ulteriormente?

Risposta breve: immagino che queste annotazioni siano utili solo per il tuo IDE per avvisarti di errori del puntatore potenzialmente nulli.

Come detto nel libro "Clean Code", dovresti controllare i parametri del tuo metodo pubblico ed evitare anche di controllare gli invarianti.

Un altro buon consiglio non è mai restituire valori null, ma utilizzare invece Null Object Pattern .

Oltre al tuo IDE che ti dà suggerimenti quando passi nulla metodi che prevedono che l'argomento non sia nullo, ci sono ulteriori vantaggi:

• Gli strumenti di analisi del codice statico possono testare lo stesso del tuo IDE (ad es. FindBugs)
• È possibile utilizzare AOP per verificare queste affermazioni

Questo può aiutare il tuo codice a essere più gestibile (poiché non hai bisogno di nullcontrolli) e meno soggetto a errori.

Penso che questa domanda originale indichi indirettamente una raccomandazione generale secondo cui è ancora necessario il controllo del puntatore null di runtime, anche se viene utilizzato @NonNull. Fare riferimento al seguente link:

Nuove annotazioni di tipo Java 8

Nel blog sopra, si consiglia di:

Le annotazioni di tipo opzionali non sostituiscono la convalida di runtime Prima delle annotazioni di tipo, la posizione principale per la descrizione di elementi come nullability o intervalli era nel javadoc. Con le annotazioni del tipo, questa comunicazione viene inserita nel bytecode in modo da consentire la verifica in fase di compilazione. Il codice deve comunque eseguire la convalida del runtime.

Compilando l'esempio originale in Eclipse alla conformità 1.8 e con l'analisi null basata su annotazioni abilitata, viene visualizzato questo avviso:

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

Questo avviso è formulato in analogia a quegli avvisi che ricevi quando mescoli il codice generato con il codice legacy usando tipi non elaborati ("conversione non selezionata"). Qui abbiamo la stessa identica situazione: il metodo indirectPathToA()ha una firma "legacy" in quanto non specifica alcun contratto nullo. Gli strumenti possono facilmente segnalarlo, quindi ti inseguiranno in tutti i vicoli in cui è necessario propagare le annotazioni null ma non lo sono ancora.

E quando si usa un intelligente @NonNullByDefaultnon dobbiamo nemmeno dirlo ogni volta.

In altre parole: se le annotazioni null "propagarsi molto lontano" possono dipendere dallo strumento che si utilizza e da quanto rigorosamente si presta attenzione a tutti gli avvisi emessi dallo strumento. Con TYPE_USE annotazioni nulle hai finalmente la possibilità di lasciare che lo strumento ti avverta di ogni possibile NPE nel tuo programma, perché la nullità è diventata una proprietà intrisica del sistema di tipi.

Concordo sul fatto che le annotazioni "non si propagano molto lontano". Tuttavia, vedo l'errore dalla parte del programmatore.

Capisco l' Nonnullannotazione come documentazione. Il seguente metodo esprime ciò che richiede (come condizione preliminare) un argomento non nullo x.

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

Il frammento di codice seguente contiene quindi un bug. Il metodo chiama directPathToA()senza imporre che ysia nullo (ovvero, non garantisce il presupposto del metodo chiamato). Una possibilità è quella di aggiungere anche Nonnullun'annotazione a indirectPathToA()(propagando la precondizione). La seconda possibilità è verificare la nullità di yin indirectPathToA()ed evitare la chiamata a directPathToA()quando yè null.

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

Quello che faccio nei miei progetti è attivare la seguente opzione nell'ispezione del codice "Condizioni e eccezioni costanti":
suggerire l'annotazione @Nullable per i metodi che possono eventualmente restituire valori null e riportare valori nullable passati a parametri non annotati

Quando attivato, tutti i parametri non annotati saranno trattati come non null e quindi vedrai anche un avviso sulla tua chiamata indiretta:

clazz.indirectPathToA(null); 

Per controlli ancora più efficaci, il Checker Framework può essere una buona scelta (vedi questo bel tutorial .
Nota : non l'ho ancora usato e potrebbero esserci problemi con il compilatore Jack: vedi questo bugreport

In Java userei il tipo opzionale di Guava . Essendo un tipo reale ottieni garanzie del compilatore sul suo utilizzo. È facile aggirarlo e ottenere un NullPointerException, ma almeno la firma del metodo comunica chiaramente cosa si aspetta come argomento o cosa potrebbe restituire.

Se usi Kotlin, supporta queste annotazioni di nullability nel suo compilatore e ti impedirà di passare un metodo null a un metodo java che richiede un argomento non null. Tuttavia, sebbene questa domanda fosse originariamente indirizzata a Java, menziono questa funzionalità di Kotlin perché è specificamente indirizzata a queste annotazioni Java e la domanda era "Esiste un modo per rendere queste annotazioni più rigorosamente applicate e / o diffondersi ulteriormente?" e questa funzione rende queste annotazioni più rigorosamente applicate .

Classe Java tramite @NotNullannotazione

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

Classe Kotlin che chiama la classe Java e passa null per l'argomento annotato con @NotNull

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

Errore del compilatore di Kotlin che impone l' @NotNullannotazione.

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

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

Dalla nuova funzionalità di Java 8 opzionale non è più necessario utilizzare @Nullable o @Notnull nel proprio codice . Prendi l'esempio seguente:

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

Potrebbe essere riscritto con:

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

L'uso di un facoltativo ti obbliga a verificare il valore null . Nel codice sopra, puoi accedere al valore solo chiamando il getmetodo.

Un altro vantaggio è che il codice diventa più leggibile . Con l'aggiunta di ifPresentOrElse di Java 9 , la funzione potrebbe anche essere scritta come:

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