Quelle @NotNull Java choisir ? Analyse sous le capot

La malédiction de NullPointerException : choisir la bonne @NotNull

Si vous avez déjà écrit en Java, vous avez sûrement rencontré NullPointerException (NPE). C'est sans doute l'erreur la plus fréquente qui fait planter la production. Les développeurs ont trouvé une manière élégante de la combattre : les annotations @NotNull et @Nullable. Mais voilà le problème : dans le monde Java, il existe au moins une dizaine d'implémentations différentes de cette annotation provenant de différents fournisseurs. Laquelle choisir ? Pourquoi y en a-t-il autant ? Et que se passe-t-il « sous le capot » lorsque vous utilisez @NotNull ?

Sur Stack Overflow, la question "Which @NotNull Java annotation should I use?" a recueilli des milliers de vues et des centaines de votes. C'est un véritable casse-tête pour les débutants comme pour les experts. Dans cet article, nous allons détailler toutes les options principales, montrer du code réel et donner un plan d'action clair. C'est parti !

Pourquoi les annotations @NotNull sont-elles nécessaires ?

Java est un langage à typage statique, mais il ne peut pas distinguer les références null des non-null au niveau des types (contrairement à Kotlin ou Rust). Les annotations sont des métadonnées qui indiquent au compilateur, à l'IDE ou à l'analyseur statique : « Hé, regarde, ce champ ne doit jamais être null ! ».

L'utilisation de @NotNull offre trois avantages clés :

\n
• Détection précoce des erreurs — l'IDE mettra en évidence un NPE potentiel avant même l'exécution.
\n
• Documentation du code — le développeur voit immédiatement le contrat de la méthode.
\n
• Intégration avec les outils — Lombok, Checker Framework, FindBugs et d'autres utilisent ces annotations pour la génération de code et les vérifications.
\n

Le problème est que chaque grand écosystème (JetBrains, Google, Eclipse, Oracle) a créé sa propre version. Passons-les en revue dans l'ordre.

Les principaux candidats : qui est qui

1. javax.annotation.Nonnull (FindBugs / JSR-305)

C'était le premier « standard de facto ». Annotation du package javax.annotation (JSR-305).

import javax.annotation.Nonnull;\n\npublic class UserService {\n    public String greet(@Nonnull String name) {\n        return "Hello, " + name;\n    }\n}

Avantages : historiquement populaire, prise en charge par les anciens outils (FindBugs, IntelliJ IDEA avec plugin).
\nInconvénients : JSR-305 est resté à l'état de « brouillon » et n'a jamais fait partie de Java SE. La bibliothèque com.google.code.findbugs:jsr305 n'est plus mise à jour depuis longtemps. Déconseillé pour les nouveaux projets.

2. jakarta.annotation.Nonnull (Jakarta EE)

Après le passage de Java EE à la Eclipse Foundation, le package javax.* a été renommé en jakarta.*. L'annotation jakarta.annotation.Nonnull en est l'héritière moderne.

import jakarta.annotation.Nonnull;\n\npublic class RestController {\n    public void process(@Nonnull String data) {\n        // data garantie non nulle\n    }\n}

Avantages : officiellement prise en charge, fait partie de Jakarta EE 9+, a une chance d'être standardisée.
\nInconvénients : nécessite l'ajout de la dépendance jakarta.annotation-api. Tous les outils d'analyse ne se sont pas mis à jour.

3. org.jetbrains.annotations.NotNull (IntelliJ IDEA)

L'annotation la plus populaire parmi les utilisateurs d'IntelliJ. Distribuée dans la bibliothèque org.jetbrains:annotations.

import org.jetbrains.annotations.NotNull;\n\npublic class DataValidator {\n    public boolean validate(@NotNull String input) {\n        return input.length() > 3;\n    }\n}

Avantages : excellente intégration avec IntelliJ IDEA (surlignage, inspections, génération automatique de vérifications). Dépendance légère (seulement 26 Ko).
\nInconvénients : liée à l'IDE JetBrains. Si l'équipe utilise Eclipse ou VS Code, l'effet est moindre.

4.