Comment utiliser plus efficacement les annotations @Nullable et @Nonnull?

Je peux voir que @Nullableet les @Nonnullannotations pourraient être utiles pour empêcher les NullPointerExceptions, mais elles ne se propagent pas très loin.

• L'efficacité de ces annotations diminue complètement après un niveau d'indirection, donc si vous n'en ajoutez que quelques-unes, elles ne se propagent pas très loin.
• Étant donné que ces annotations ne sont pas bien appliquées, il y a un risque de supposer qu'une valeur marquée par @Nonnulln'est pas nulle et par conséquent de ne pas effectuer de vérifications nulles.

Le code ci - dessous provoque un paramètre marqué par @Nonnullêtre nullsans soulever de plaintes. Il jette un NullPointerExceptionquand il est exécuté.

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

Existe-t-il un moyen de rendre ces annotations plus strictement appliquées et / ou de se propager davantage?

Réponse courte: je suppose que ces annotations ne sont utiles que pour que votre IDE vous avertisse des erreurs de pointeur potentiellement nulles.

Comme dit dans le livre "Clean Code", vous devriez vérifier les paramètres de votre méthode publique et aussi éviter de vérifier les invariants.

Un autre bon conseil est de ne jamais renvoyer de valeurs nulles, mais d'utiliser à la place un motif d'objet nul .

Outre que votre IDE vous donne des conseils lorsque vous passez nullà des méthodes qui s'attendent à ce que l'argument ne soit pas nul, il y a d'autres avantages:

• Les outils d'analyse de code statique peuvent tester le même que votre IDE (par exemple FindBugs)
• Vous pouvez utiliser AOP pour vérifier ces assertions

Cela peut aider votre code à être plus maintenable (puisque vous n'avez pas besoin de nullvérifications) et moins sujet aux erreurs.

Je pense que cette question originale pointe indirectement vers une recommandation générale selon laquelle la vérification du pointeur nul au moment de l'exécution est toujours nécessaire, même si @NonNull est utilisé. Reportez-vous au lien suivant:

Nouvelles annotations de type de Java 8

Dans le blog ci-dessus, il est recommandé que:

Les annotations de type facultatives ne remplacent pas la validation d'exécution Avant les annotations de type, l'emplacement principal pour décrire des éléments tels que la nullité ou les plages était dans le javadoc. Avec les annotations de type, cette communication entre dans le bytecode d'une manière pour la vérification à la compilation. Votre code doit toujours effectuer la validation d'exécution.

En compilant l'exemple d'origine dans Eclipse à la conformité 1.8 et avec l'analyse nulle basée sur les annotations activée, nous obtenons cet avertissement:

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

Cet avertissement est formulé par analogie avec les avertissements que vous recevez lorsque vous mélangez du code généré avec du code hérité en utilisant des types bruts ("conversion non cochée"). Nous avons exactement la même situation ici: la méthode indirectPathToA()a une signature «héritée» en ce qu'elle ne spécifie aucun contrat nul. Les outils peuvent facilement signaler cela, ils vous poursuivront donc dans toutes les allées où des annotations nulles doivent être propagées mais ne le sont pas encore.

Et lorsque vous utilisez un intelligent, @NonNullByDefaultnous n'avons même pas à le dire à chaque fois.

En d'autres termes: le fait que les annotations nulles "se propagent très loin" peut dépendre de l'outil que vous utilisez et de la rigueur avec laquelle vous vous occupez de tous les avertissements émis par l'outil. Avec les annotations nulles TYPE_USE, vous avez enfin la possibilité de laisser l'outil vous avertir de tous les NPE possibles dans votre programme, car la nullité est devenue une propriété intrinsèque du système de types.

Je conviens que les annotations "ne se propagent pas très loin". Cependant, je vois l'erreur du côté du programmeur.

Je comprends l' Nonnullannotation comme une documentation. La méthode suivante exprime qu'elle requiert (comme condition préalable) un argument non nul x.

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

L'extrait de code suivant contient alors un bogue. La méthode appelle directPathToA()sans appliquer ce qui yest non nul (c'est-à-dire qu'elle ne garantit pas la condition préalable de la méthode appelée). Une possibilité est d'ajouter également une Nonnullannotation à indirectPathToA()(propager la précondition). La deuxième possibilité consiste à vérifier la nullité de yin indirectPathToA()et à éviter l'appel à directPathToA()when yis null.

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

Ce que je fais dans mes projets est d'activer l'option suivante dans l'inspection de code "Conditions constantes et exceptions":
Suggérer une annotation @Nullable pour les méthodes qui peuvent éventuellement renvoyer null et signaler des valeurs nullables passées à des paramètres non annotés

Lorsqu'il est activé, tous les paramètres non annotés seront traités comme non nuls et vous verrez donc également un avertissement sur votre appel indirect:

clazz.indirectPathToA(null); 

Pour des vérifications encore plus solides, le Checker Framework peut être un bon choix (voir ce joli tutoriel .
Remarque : je ne l'ai pas encore utilisé et il peut y avoir des problèmes avec le compilateur Jack: voir ce rapport de bogue

En Java, j'utiliserais le type facultatif de Guava . Étant un type réel, vous obtenez des garanties du compilateur sur son utilisation. Il est facile de le contourner et d'obtenir un NullPointerException, mais au moins la signature de la méthode communique clairement ce qu'elle attend en tant qu'argument ou ce qu'elle pourrait renvoyer.

Si vous utilisez Kotlin, il prend en charge ces annotations de nullabilité dans son compilateur et vous empêchera de passer un null à une méthode java qui nécessite un argument non nul. Même si cette question était à l'origine ciblée sur Java, je mentionne cette fonctionnalité Kotlin car elle est spécifiquement ciblée sur ces annotations Java et la question était "Y a-t-il un moyen de rendre ces annotations plus strictement appliquées et / ou de se propager davantage?" et cette fonctionnalité rend ces annotations plus strictement appliquées .

Classe Java utilisant l' @NotNullannotation

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

Classe Kotlin appelant la classe Java et passant null pour l'argument annoté avec @NotNull

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

Erreur du compilateur Kotlin lors de l'application de l' @NotNullannotation.

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

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

Depuis la nouvelle fonctionnalité Java 8 en option, vous ne devez plus utiliser @Nullable ou @Notnull dans votre propre code . Prenons l'exemple ci-dessous:

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

Il pourrait être réécrit avec:

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

L'utilisation d'une option vous oblige à vérifier la valeur nulle . Dans le code ci-dessus, vous ne pouvez accéder à la valeur qu'en appelant la getméthode.

Un autre avantage est que le code devient plus lisible . Avec l'ajout de Java 9 ifPresentOrElse , la fonction pourrait même être écrite comme suit :

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