Discussion :

[grunt2000]

Bonjour,

En passant du JDK 6 au 7, j'ai fait l'effort de remplacer tous mes Validate.assertNotNull() (d'apache commons) qui vérifiaient les paramètres des méthodes publiques que j'exposais par des Objects.requireNotNull().
Aujourd'hui, en arrivant au JDK 8, je suis incité à employer l'annotation javax.annotation.Nonnull.

Mais j'ai deux problèmes :

1) import javax.annotation.Nonnull n'est pas reconnu.

Je n'arrive pas à comprendre comment faire pour que cela compile et surtout, pour que cela s'enclenche ensuite.
- Dans mon projet Maven, je rajoute quelle dépendance pour qu'il complète le package javax.annotation avec cette nouvelle annotation ?
Je lis parfois des messages sur Internet qui disent que je devrais intégrer un "jsr305-2.0.1.jar" dans mon projet, mais le comment n'est pas très clair.
- Comment enclencher cette vérification (qui à l'air compile time seulement) ? C'est un paramètre supplémentaire à passer dans l'ordre javac de compilation ? Il faut modifier le "javac" employé pour lancer les compilation dans le projet Maven également ?


2) Du coup, j'enlève vraiment mes Objects.requireNotNull() ?

À l'exécution, dès qu'il y aura une valeur null qui transitera – via un paramètre null venu de l'extérieur (d'un web-service par exemple ou d'une base de données) – ça ne pourra quand même que planter ?!

Ou bien la bonne pratique c'est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public void maMethode(@Nonnull Parametre p) {
Objects.requireNonNull(p);
 
int x = p.getMaValeur();
...
}

? Dans ce cas là, c'est un peu redondant, mais s'il faut en passer par là...
Mon prérequis, c'est de n'avoir aucune valeur nulle à l'exécution. Il ne faut jamais que je me retrouve dans la situation où un @Nonnull aurait été accolé à un paramètre et qu'à l'exécution un null passe entre les filets et arrive aux instructions. Sinon, j'aurai dégradé mon code.

Or, j'ai l'impression que la vérification en compile time ne pourra jamais garantir cela. Je réfléchis, mais je ne vois pas comment.

Merci pour vos avis et de votre assistance,

Grunt.

[adiGuba]

Salut,

1) import javax.annotation.Nonnull n'est pas reconnu.

C'est normal : cette annotation n'existe pas !

Les "Types annotations" de Java permettent d'utiliser des annotations un peu partout dans le code, et non plus uniquement sur les variables/méthodes/classes.
C'est quelque chose d'utile si on veut vérifier le code automatiquement.
Par exemple jusqu'à maintenant on pouvait écrire @NonNull List<String> list pour indiquer que la liste n'est pas nulle, et désormais on peut définir aussi une annotation devant le type générique, par exemple @NonNull List<@NonNull String> list pour indiquer que la liste n'est pas nulle, tout comme chacun de ses éléments.

Mais ce ne sont que des exemples, et ces annotations n'existent pas en standard !
Il te faudra passer par un outils externes pour gérer cela (tel FindBugs).

Je lis parfois des messages sur Internet qui disent que je devrais intégrer un "jsr305-2.0.1.jar" dans mon projet, mais le comment n'est pas très clair.

La JSR 305 avait pour objectif de proposer un ensemble d'annotations standard pour gérer cela, car chaque outils utilisent les siennes (ex : edu.umd.cs.findbugs.annotations.NonNull pour FindBugs).
La JSR n'a pas été intégré et semble "morte", mais elle a quand même défini les annotations que l'on peut retrouver dans ce jar.

Mais encore une fois il s'agit des annotations seules, et il faudra un outils à coté pour les gérer... si il gère bien ces annotations.

- Comment enclencher cette vérification (qui à l'air compile time seulement) ? C'est un paramètre supplémentaire à passer dans l'ordre javac de compilation ? Il faut modifier le "javac" employé pour lancer les compilation dans le projet Maven également ?

En théorie ce devrait être un processeur d'annotation. Cela devrait s'exécuter automatiquement avec javac lorsque le jar est dans le classpath.
Donc en gros il suffit d'ajouter le jar de l'outil en question dans le classpath à la compilation pour que le traitement soit fait.

Et oui c'est bien du compile-time !

2) Du coup, j'enlève vraiment mes Objects.requireNotNull() ?

Non garde les !


a++

[grunt2000]

Merci !
Je me disais bien qu'il y avait quelque-chose qui ne tournait pas rond !

Je vais mettre Résolu sur le fil, même si j'ai l'impression d'avoir consacré quelques heures à un beau coup d'épée dans l'eau !
Ils en ont beaucoup des comme ça à nous proposer pour Java 8 ? Des trucs qu'on lit, plus ou moins officiels, mais en fait il ne faut pas y croire ?! C'est piégeux.

[thelvin]

Ouais enfin, j'ai lu pas mal de trucs sur Java 8, et j'ai pas le souvenir qu'un seul d'entre eux m'ait parlé de cette annotation.

[grunt2000]

Ouais enfin, j'ai lu pas mal de trucs sur Java 8, et j'ai pas le souvenir qu'un seul d'entre eux m'ait parlé de cette annotation.

Tu as raison ! Et pourtant, le fait que quand elle s'intègre, elle s'intègre dans le package javax.annotation, montre bien que c'est une fonctionnalité qui a été voulue par les concepteurs.
Car javax comme java sont des racines de packages réservés que n'importe qui n'est pas autorisé à compléter (à moins que je ne me trompe !).

[adiGuba]

Tu as raison ! Et pourtant, le fait que quand elle s'intègre, elle s'intègre dans le package javax.annotation, montre bien que c'est une fonctionnalité qui a été voulue par les concepteurs.
Car javax comme java sont des racines de packages réservés que n'importe qui n'est pas autorisé à compléter (à moins que je ne me trompe !).

Pas forcément : le package javax c'est pour des "API d'extensions" et cela peut regrouper plusieurs chose qui n'appartiennent pas forcément à l'API standard de base, et qui ne sont pas forcément destiné à y être intégré !
Cela peut correspondre à :

• Des API incluent dans l'API standard de Java SE (javax.swing, javax.xml, ...)
• Des API incluent dans l'API standard de Java EE (javax.ejb, javax.servlet, ...)
• Des API autonome (javax.mail pour Java Mail, javax.jnlp pour Java Web Start, ...)

Le problème c'est que javax.annotations fait un peu partie des 3 catégories :

• Java SE définie les annotations @Generated, @PostConstruct, @PreDestroy, @Resource, et @Resources.
• Java EE y rajoute @ManagedBeans
• Et la JSR 305 y rajoute plusieurs annotations pour les outils de contrôles de codes (@NonNull, ...)

Mais une chose est certaines : le package javax.annotations ne fait que fournir des annotations de base, et qu'elle ne sont pas forcément destiné à fonctionner toute seule.
En clair il faut toujours un outil externe pour les utiliser.

L'intérêt du package vient de la standardisation des annotations, ce qui permet de changer d'outils plus facilement.


a++