Lombok en pratique

ScreenHunter_423 Jul. 11 15.12

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:

  1. 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)
  2. 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

Project Lombok v1.16.8 - Installer_024

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é.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.