@Nullable et @NonNull

Le framework Checker propose plein d'annotations sympa à placer dans le code pour le sécuriser.

Il permet notamment de répondre au besoin de nullabilité des types (et des retours de fonction): Une fonctionnalité qui existe en Kotlin (par exemple String? qui défini un String possiblement null), mais qui n'existe pas en Java.

L'idée derrière tout ça est évidemment de faciliter l'intéropérabilité avec Kotlin, mais pas que !

En effet, les IDE sont capables de prendre en compte ces annotations et proposer des corrections de code pour éviter de potentielles erreurs.

Indiquer la potentielle nullité

Avec @Nullable, une fonction pourrait retourner null.

Par exemple:

@Nullable  
public String creerDossier(DemandeCreationDossier demande) {  
   // Dans cet exemple, la demande peut retourner null cas d'erreur métier
   var demande = creerDossier(demande)
   return demande;
}

Si après le code appelant, un accès à la variable est réalisé, l'IDE nous informe que ce code peut lever une erreur et qu'il serait préférable de l'encadrer avec un test de nullité.

Indiquer l'impossibilité de nullité

Avec @NonNull, on indique qu'une fonction est assurée de ne pas retourner null.

@NonNull  
public String creerDossier(DemandeCreationDossier demande) throws BusinessException {  
   // Dans cet exemple, la demande est crée ou un BusinessException est levée en cas d'erreur métier
   verifierDemande(demande); 
   // vérification métiers, etc...
   var demande = creerDossier(demande)
   return demande;
}

Si dans le code un test de nullité est réalisé, l'IDE nous informe que ce test est superflu.

Et également sur les variables ...

Evidemment cette approche fonctionne également sur les variables.

@NonNull String numeroDossier = null;

@Nullable Car car = findFirstCar(xxx);

Pour aller plus loin :

• Ces annotations ont beaucoup d'homonymes. C'est le package org.checkerframework.checker.nullness.qual qu'il faut utiliser
• Le Checker Framework propose pleins d'autres annotations de contrôle, mais 🥱 la doc est très spartiate !
• JSR 305 qui voulait standardiser ces annotations... qui n'a malheureusement jamais été validé
• Bonne pratique de dev : Avoid Null Values if possible.