IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Tutoriel pour explorer la bibliothèque Lombok par la pratique en 5 minutes

Image non disponible

Ce tutoriel vous apprend à découvrir la bibliothèque Lombok utilisée pour la génération de codes à partir d'annotations.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum 10 commentaires Donner une note à l´article (5).

Article lu   fois.

Les deux auteurs

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

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.

 
Sélectionnez
1.
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.
Image non disponible

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 :

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

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Copyright © 2017 Netapsys. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.