septembre
2006
Un article de adiGuba
Certain EDI tel qu’IntelliJ IDEA ou des outils de vérification de code comme FindBugs ont mis en place un mécanisme de détection d’erreur basé sur les annotations. Concrètement, plusieurs éléments du code peuvent être marquées avec des annotations avec d’apporter une information complémentaire sur leur utilisation. Ce peut ainsi permettre à ces outils de détecter de mauvaises utilisations et d’afficher des warnings ou erreurs pour en avertir le développeur…
Si ce type de vérification peut se révéler très utile, cela souffre d’un gros défaut : étant données que ces annotations restent spécifique et ne sont pas standard du tout, elles ne sont pas du tout portable d’un outil à l’autre. Or, si cela ne pose pas vraiment de problème pour compiler le code avec d’autres compilateurs ou EDIs, les avantages des annotations sont alors perdu. De plus, certaines annotations sont présentes dans différents outils sous des noms différents tout en proposant des fonctionnalités similaires…
Or pour que ce type d’outils soient vraiment utile, il faudrait que les librairies utilisent massivement ce genre d’annotation. Mais les développeurs de ces librairies ne sont pas prêt à investir leurs temps à renseigner ces annotations s’il s’avère qu’elles ne sont pas portable, ou qu’elles ne peuvent être utilisées qu’avec un EDI ou outil spécifique…
Une nouvelle JSR vient d’être créée afin de résoudre ce problème en proposant un ensemble d’annotations standards qui pourraient être utilisées par ces outils de détection d’erreurs. Cette JSR se base entre autre sur les annotations d’IntelliJ et de FindBugs. D’ailleurs JetBrains (l’éditeur d’IntelliJ IDEA) et William Pugh (à l’origine de FindBugs) font partie du groupe d’expert de cette JSR…
Outre les annotations @Nullable et @NotNull qui permettent d’indiquer si élément (champs, variables locales, paramètres, retour de méthodes) peut prendre une valeur null ou pas, IntelliJ propose les annotations @Nls et @NonNls pour indiquer si une chaîne de caractères doit être internationalisé ou pas.
FindBugs permet également de vérifier que la valeur de retour d’une méthode ne soit pas ignorée avec @CheckReturnType, d’obliger les redéfinitions de méthode à appeler leur méthode « parente » avec @OverrideMustInvoke, ou encore de définir des annotations par défaut pour toutes une classe/package avec @DefaultAnnotation, @DefaultAnnotationForFields, @DefaultAnnotationForMethods et @DefaultAnnotationForParameters…
La JSR cite également d’autres exemples provenant du livre Java Concurrency in Practice, comme @ThreadSafe et @NotThreadSafe qui permettent d’indiquer si une classe est thread-safe ou non, ou encore @GuardedBy qui implique que certaines méthodes soient utilisées seulement lorsque un certain lock a été acquis (avec un bloc synchronized). Ou encore l’annotation @Immutable qui permet de signaler qu’une classe est immuable (ce qui pourraient être vérifié par des outils).
On peut encore imaginer toutes sortes d’annotations qui pourrait ajouter des contraintes diverses (comme par exemple un @Const qui simulerait le fonctionnement du mot-clef const de C++). Et si ces annotations deviennent standard, il y a de fortes chances qu’elles soient utilisées par un grand nombre d’outil…
Tutoriels
Discussions
- Classes, méthodes private
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- Difference de performances Unix/Windows d'un programme?
- Possibilité d'accéder au type générique en runtime
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- [ fuite ] memoire
- Recuperation du nom des parametres
- jre 1.5, tomcat 6.0 et multi processeurs
- Définition exacte de @Override