Un blog précèdent que vous trouverez ici, nous faisait découvrir la librairie Lombok.
Cette librairie 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 librairie 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.
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() and equals()' et pour 'toString()'". Au final le code généré est identique, donc quels avantages ?
1 - 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.
2 - 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 refactoré 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ésents attribuait une valeur par défaut en cas de nullité ou une autre rustine de développeur.
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 sont trop impactantes ou 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 :
Utilisation dans le cadre d'un projet Maven
Bien sur dans le cadre d'un projet Maven il faut que la librairie lombok.jar soit ajoutée aux dépendances du projet.
<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>
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 (tips : si c'est un projet Maven elle est sûrement déjà dans votre repo local)
- exécuter le jar : une interface graphique vous propose de sélectionner votre IDE (si il n'a pas été trouvé automatiquement) et vous le configure automatiquement
Petite astuce : 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éferences workspace, Pull up, ...
Annotations utilisées dans le cadre de notre projet
@Getter et @Setter
La base de tout ou comment diminuer par 5 la taille de vos classes en édition et donc de faciliter leur lecture.
@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) !
@AllArgsConstructor
Utilisé à faible dose pour permettre de tester facilement certaines classes.
@NoArgsConstructor
En complément du @AllArgsConstructor.
@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 parait 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, CommonsLog de appache ou Log de java.
Les annotations que j'aimerais bien tester
@UtilityClass
Suffisamment rare pour ne pas en avoir besoin mais on ne sait jamais.
@Builder
Pour la construction en DSL.
@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
@Delegate
Ajoute les getters/setters des propriétés d'un bean de composition au bean principal.
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 de eclipse du fait des méthodes surnuméraires.
Conclusion
Lombok est une librairie 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é.