NormandyJUG – annotations
Mardi dernier, j’ai assisté lors de la session du NormandyJUG à la présentation d’Olivier Croisier sur les annotations. Autant le dire tout de suite : je ne suis pas fan des annotations. J’ai beaucoup de mal avec cette mode de mettre des éléments de configuration dans du code source. On nous rabâche depuis des années que le code source doit être réutilisable et donc générique. Or que depuis l’apparition des annotations, je vois beaucoup de code contenant du paramétrage. On se retrouve donc avec des binaires liés à un environnement. 
Néanmoins, c’est sans apriori que je me suis rendu à cette session. Espérant, apprendre quelque chose et peut-être changer d’avis. 
Introduction
En regardant en arrière, on se rend compte qu’XDoclet est l’ancêtre des annotations. Ce système utilisait déjà une méthode de paramétrage et/ou injection/génération de code à partir d’”@” dans la JavaDoc. Cette implémentation avait deux défauts :
- tout n’est pas documentable dans le langage Java
- la documentation disparait à la compilation
Voilà pourquoi la création des annotation était nécessaire.
Afin d’assurer une compatibilité du byte code avec le Java <=4, l’implémentation des annotations réutilise les concepts existants dans la langage d’une façon parfois déroutante…
Annotations personnalisées
Pourquoi ?
- remplacer les fichiers de configuration
- simplifier le code avec la meta-programmation
- ajouter des règles de compilation
Caractéristiques
- un champ d’action
- une durée de vie (source, compilation, exécution)
La compilation
Les annotations permettent de réaliser un plugin pour le compilateur (Java >=6) via les Pluggable Annotation Processor. Ceci permet entre autre de casser le build. Ce qui peut de révéler très pratique pour faire respecter des best pratices de développement.
Pourquoi ?
- La génération de ressources
- La configuration
- Les classes
- La documentation
- L’amélioration du compilateur
- Norme de codage
- Message d’erreur
A ce stade de la présentation, Olivier met en garde l’utilisation de certain framework tel de Lombok qui a quelques contraintes tel que la dépendance de la compilation. En effet, votre compilateur doit être supporté par le projet. Comme toujours, c’est à vous d’estimer le ratio entre risques et avantages.
Comment ?
Ces annotations sont implémentées via AbstractProcessor. Une API permet de faire de l’introspection et découvrir dynamiquement les annotations. Nous avons le droit à une petite démo avec le SerializableClassesProcessor.
Le runtime
Pourquoi ?
- Le mapping
- Les POJO
- La configuration et/ou les frameworks
Notre intervenant nous illustre cela avec un CSVReader.
Aller plus loin…
Pour nous montrer ce qu’il est possible de faire avec les annotations, notre invité nous présente alors son proof of concept d’injection d’annotations : AnnotationInjector. Il nous avoue que c’est un framework assez sympa à réaliser mais qu’il n’a pas encore trouvé son utilité ! 
La conclusion
Une session très enrichissante qui ma réconcilié avec les annotations ! J’éviterai toujours les éléments de configuration dans le code (surtout s’il est lié à un environnement tel que développement, recette ou production). Néanmoins, j’ai déjà testé les Annotations Processor. Et les sembles prometteuses. 
La session se termine par une présentation de seren. Cet outil, réalisé par Olivier Crosier, a pour objectif d’optimiser les temps de traitement de la sérialisation et de désérialisation.
Si ce compte-rendu vous a donné envie de vous mettre aux annotations, sachez que la présentation et le code source est disponible sur GitHub.