.
I. Introduction▲
Lombok permet de générer à la compilation les principales méthodes et bouts de codes génériques par l'utilisation d'annotations. De puis longtemps, je voulais essayer à l'échelle d'un projet l'utilisation de la bibliothèque Lombok. L'occasion s'étant enfin présentée, je vous propose de faire un petit retour sur sa mise en pratique dans le monde réel.
II. Pourquoi utiliser Lombok▲
L'annotation par excellence @Data permet, par exemple de générer l'ensemble des getters et setters de votre classe, mais aussi les méthodes toString(), hashCode() et equals() dont l'implémentation ne nécessite normalement aucune réflexion particulière.
Vous me direz "Oui, mais sous Eclipse il suffit de faire 'clic droit > Source > Generate Getters/Setters' et de même pour hashCode(), equals() et pour toString()". Finalement le code généré est identique, donc quels avantages ?
II-A. La lisibilité▲
En effet Lombok générant ces méthodes à la compilation, leur code n'apparaît pas lors de l'édition de votre classe.
Une classe classique ne contiendra pas plus que les attributs privés (dont les getters/setters découlent) et les méthodes custom, soit uniquement le code ayant nécessité le cerveau d'un développeur.
II-B. La facilité de refactoring▲
La classe ne contenant plus que les méthodes custom, il devient très facile d'identifier l'impact d'un changement de nom de propriété.
Je ne compte même plus le nombre de fois ou j'ai utilisé le refactoring pour une classe en supprimant les getters/setters et en les générant de nouveau avec les noms de propriétés modifiés (avec Eclipse) pour me rendre compte plus tard, qu'un des setters parmi la vingtaine présente, attribuait une valeur par défaut en cas de nullité ou une autre rustine de développeur.
III. Retour d'expérience▲
Nous utilisons la version 1.16.8 de Lombok sur un projet Maven JDK8 depuis plus de trois mois. Après une courte phase de rodage et en essayant de ne pas trop abuser des bonnes choses (certaines annotations ont trop de répercussions ou ne sont pas assez implicites), le résultat est plutôt concluant et nous sommes en train de réfléchir à le généraliser sur les autres projets associés.
Pour l'installation, tout est documenté sur le site : projectlombok.org, mais voici la config dans notre cas spécifique :
III-A. Utilisation dans le cadre d'un projet Maven▲
Bien sûr dans le cadre d'un projet Maven il faut que la bibliothèque lombok.jar soit ajoutée aux dépendances du projet.
2.
3.
4.
5.
6.
7.
8.
<dependency>
<!-- Librairie permettant de générer auto les codes classiques (get/set,log,...) -->
<!-- @see https://projectlombok.org -->
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>${lombok.version}</version>
<scope>provided</scope>
</dependency>
III-B. Utilisation dans le cadre d'un projet édité sous Eclipse▲
Eclipse réalisant des pré-compilations à la volée pour permettre l'utilisation de l'ensemble de ses fonctionnalités, il faut qu'il soit dans son classpath le lombok.jar. Pour cela, rien de plus simple :
- télécharger le jar de la version correspondante à votre projet (astuces : si c'est un projet Maven elle est sûrement déjà dans votre dossier local Maven) ;
- exécuter le jar : une interface graphique vous propose de sélectionner votre IDE (s'il n'a pas été trouvé automatiquement) et vous le configure automatiquement.
Vous pouvez voir les méthodes générées par lombok dans la vue Outline de votre perspective Eclipse préférée. Ceci vous permet de faire vos actions habituelles de type Références workspace, Pull up...
III-C. Annotations utilisées dans le cadre de notre projet▲
III-C-1. @Getter et @Setter▲
La base de tout ou comment diviser par cinq la taille de vos classes en édition et donc de faciliter leur lecture.
III-C-2. @Data▲
L'annotation qui sert à tout, mais finalement assez peu utilisée (généralement dans des classes mères pour des raisons architecturales), car la plupart du temps, les @Getter / @Setter suffisent et que plus de méthodes n'est pas forcément mieux (même si elles sont générées à la compilation) !
III-C-3. @AllArgsConstructor▲
Utilisé à faible dose pour permettre de tester facilement certaines classes.
III-C-4. @NoArgsConstructor▲
En complément du @AllArgsConstructor.
III-C-5. @Slf4j▲
Annotation permettant de générer la sacro-sainte ligne :
private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(LogExample.class);Cela paraît tout bête, mais là encore je ne compte pas le nombre d'erreurs de copier-coller où le nom de classe initialisant le logger n'a pas été changé, et on se retrouve avec une log de MyClass.java sous le nom de MyOtherClass.java.
Il existe les équivalents Log4j, Apache CommonsLog ou Log de Java.
III-D. Les annotations que j'aimerais bien tester▲
III-D-1. @UtilityClass▲
Suffisamment rare pour ne pas en avoir besoin, mais on ne sait jamais.
III-D-2. @Builder▲
Pour la construction en DSL.
III-D-3. @CleanUp▲
Plus ou moins obsolète depuis Java7 mais pourquoi pas sur des projets Java6 ou antérieurs : https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html.
III-D-4. @Delegate▲
Ajoute les getters/setters des propriétés d'un bean de composition au bean principal.
III-E. Les bémols▲
La Javadoc générée est inexistante et n'utilisera pas vos préférences Eclipse, par conséquent ce sont généralement les attributs de votre classe qui devront porter les informations. Quelques erreurs surviennent parfois en concurrence avec les Save Actions d'Eclipse du fait des méthodes surnuméraires.
IV. Conclusion▲
Lombok est une bibliothèque très pratique permettant de faciliter grandement la lisibilité du code et sa maintenance. Elle doit néanmoins être utilisée de manière maîtrisée, car l'abus d'annotations peut parfois avoir l'effet inverse de celui escompté.
V. Remerciements▲
Cet article a été publié avec l'aimable autorisation de Netapsys.
Nous tenons à remercier jacques_jean pour la relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.