Discussion :

[Bill Fassinou]

Lombok, une bibliothèque Java, rend la programmation Java plus simple en facilitant l'écriture de vos classes,
selon un ingénieur

« Lombok rend Java plus cool à nouveau », a écrit Alex Detrick, ingénieur au sein de GrubHub, une société américaine de commande et de livraison de produits alimentaires, comme titre à son article. Connaissez-vous le projet Lombok ? Sinon, il s’agit notamment d’une bibliothèque qui se connecte automatiquement à votre éditeur ou IDE et crée des outils Java. Il épice votre code Java comme le précise son site officiel et est publié sous la licence MIT. Le projet Lombok est un outil pour le développeur pragmatique. Il fournit un ensemble d’annotations utiles pour éliminer une grande quantité de code standard de vos classes Java. Dans le meilleur des cas, cinq caractères seulement peuvent remplacer des centaines de lignes de code. Le résultat est de classes Java propres, concises et faciles à gérer. L’utilisation de Lombok est relativement simple, nous explique Alex et il est compatible avec le Gradle mais également avec Maven.

La vision autour de ce projet est de réduire les répétitions de blocs de codes dans les nombreuses parties d’une application en les remplaçant par de simples annotations. Le projet est disponible en téléchargement en tant que fichier JAR sur le site Web qui lui est consacré et intègre en même temps les API de développement et d’intégration à votre IDE. Si vous l’avez téléchargé et lancé l’installation, le programme vérifiera s’il existe sur votre ordinateur un IDE avec lequel il est compatible. Dans sa dernière version, la 1.18.4, le projet prend en charge la plupart des IDE du marché notamment NetBeans, Eclipse, IntelliJ IDEA, etc. L’ingénieur a indiqué que Lombok leur est d’une grande utilité dans l’utilisation des objets Java classiques communément appelés POJO, grâce aux annotations telles que @Data qui contient lui-même d’autres petites annotations.

Parmi les annotations filles de @Data, on trouve @ToString qui génère automatiquement une implémentation de la méthode toString() ou @Getter et @Setter pour la génération des méthodes getter et setter pour les attributs. Notons que ces annotations contenues dans la macro @Data peuvent être utilisées de façon séparée. De plus, une bonne partie de ces annotations sont également modifiables pour s’adapter à votre convenance.
D’autres annotations qu’offre Lombok ont été également présentées. Nous avons par exemple les annotations :

• @NonNull qui déclenche automatiquement une exception de type NullPointerException lorsqu’elle est placée sur un champ ;
• @Cleanup pour indiquer à la JVM que les ressources allouées doivent être libérées pour la variable concernée à la fin de l’exécution ;
• @FieldDefaults qui ajoute les modificateurs private et final à la variable concernée ;
• @UtilityClass qui rend une classe finale, crée un constructeur privé et rend toutes les méthodes de la classe statiques ;
• etc.

Vous pouvez avoir accès à la liste complète des annotations et autres fonctionnalités de Lombok sur son site Web. Pour Alex, ces annotations de Lombok confèrent à Java de nouvelles fonctionnalités et le rendent plus intéressant comme langage devant Kotlin et la concurrence. À la question de savoir quel est le réel impact ou l’avantage que cela leur procure dans le déroulement de leurs projets, il a expliqué que Lombok rend plus minimaliste et plus lisible que jamais leurs codes Java. « Grubhub a plus d'une centaine de services en cours d'exécution pour répondre aux besoins de l'entreprise. Nous avons pris l'un de ces services et avons exécuté la fonctionnalité “de-lombok” du plug-in Lombok IntelliJ pour voir combien de lignes de code ont été enregistrées à l'aide de Lombok. C'est 18 000 lignes de code générées automatiquement, standardisées et testées. En moyenne, chaque ligne de code Lombok enregistre 23 lignes de code Java. Avec un tel impact, il est difficile d’imaginer utiliser Java sans Lombok », illustre-t-il.

Par contre, certains voient la chose autrement. Un internaute a écrit en réponse à Alex qu’effectivement Lombok est une béquille utile si l’on écrit beaucoup de code Java au jour le jour. Cependant, étant donné la facilité d'utilisation de Kotlin aux côtés de Java, « je me demande si Lombok est la bonne solution au problème », s’est-il interrogé. Il a aussi ajouté que Kotlin a des classes de données qui génèrent automatiquement des méthodes comme 'toString' et 'hashCode', ce qui représente, selon lui, un gain de temps considérable.

Pour un autre, la programmation basée sur des annotations peut sembler cool maintenant, mais l’enthousiasme autour va diminuer dans quelques années. Selon lui, il est vrai qu’utiliser Lombok ou un autre outil d’annotation permet de ne pas écrire du code fastidieux. Cependant, imaginer que le temps passe, explique-t-il, vous ouvrez le projet pour détecter un bogue, seulement il peut ne pas avoir de flux logique pour raison de mise à jour du langage ou suppression d’une fonctionnalité donnée du langage, etc. Une approche alternative à Lombok, d’après lui, serait de réfléchir à la façon dont le projet a abouti à autant de classes de données inutiles. « Au lieu de penser à sauter immédiatement sur Lombok ou tout autre, posez-vous des questions ressemblant à : comment le projet pourrait-il être remanié pour éliminer ces lignes inutiles ? », a-t-il conclure.

Sources : GrubHub, Project Lombok

Et vous ?

Qu'en pensez-vous ?
Quelle est votre préférence entre Lombok et Kotlin ? Pourquoi ?

Voir aussi

Tutoriel sur l'utilisation de la bibliothèque Lombok

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

Simplifier le code de vos beans Java à l'aide de Commons Lang, Guava et Lombok

Apprendre à utiliser la bibliothèque Lombok avec le langage Java pour simplifier l'écriture de vos classes, un tutoriel de François-Xavier Robin

[dfiad77pro]

Perso je ne suis pas fan de Lombok pour plusieurs raisons.

- Je trouve les annotations data dangereuses, on ne maitrise pas ce qu'il y'a en dessous
- Oblige d'installer une extension pour que les getter/setter générés soient reconnu
- Le fait de simplifier les beans peux faire oublier les bonnes pratiques

En gros je vois souvent des POJO avec +50 propriétés et au lieux de reffactorer, on se dit pas grave, il y a Lombok


Bref autant les annotations utilisés pour l'IOC c'est super mais pour la génération de pseudo code, je suis dubitatif.

[Florent.Lebail]

Ultra simple d'utilisation, il me permet de gagner beaucoup de temps notamment quand je fais de la revue de code, pour créer mes POJO etc...

Il me permet également de voir immédiatement ce qui est implanté sur la classe et d'avoir du coup un code plus clair et plus épuré.

Par contre comme c'est précisé au dessus les personnes que je forme en Java je leur impose du code "à l'ancienne" pour prendre les bonnes pratiques après je leur montre l'équivalent sous lombok.

[Pyramidev]

De mon côté, je n'ai pas codé en Java depuis plusieurs années. Mais, le mois dernier, sur developpez.com, quand j'ai vu passer le tutoriel de François-Xavier Robin sur la bibliothèque Lombok et que j'ai jeté un œil, je me suis dit : tiens, ça a l'air pas mal, Java devient moins verbeux.

Par contre, c'est dommage que ce soit dans une bibliothèque externe au lieu d'être dans le langage de base.

En Python, depuis la version 3.7 (actuellement la dernière version), on a les data classes qui permettent de générer automatiquement certaines méthodes. Donc on a une partie des fonctionnalités de Lombok directement dans le langage.

[OButterlin]

Bon, certains diront : "normal, encore un dinosaure de la programmation" (et c'est pas faux ) mais je ne peux m'empêcher d'être dubitatif devant ce genre de choses qualifiées "d'avancées" d'un langage de programmation...
Mettre une annotation @getter @setter devant un attribut, ou @FieldDefaults(level=AccessLevel.PRIVATE) pour ne pas avoir à le mettre devant l'attribut... à croire que les langages doivent utiliser un forfait lettres et que le meilleur est celui qui en utilise le moins...

Personnellement, ça me prend 15 secondes pour faire générer les getter/setter, la méthode toString, le(s) constructeur(s), les méthodes hashCode/equals avec Eclipse alors je me demande : où est l'intérêt ?

Qui plus est, j'utilise très souvent le setter pour monter un flag de modification, je ne pense pas qu'on puisse faire l'équivalent avec l'annotation @setter, idem pour hashCode sur mes clés primaires que je modifie "légèrement" par rapport à ce qui est fait par défaut...

On peut comprendre que les méthodes type getter/setter, toString, hashCode equals prennent de la place qui peut rendre le code un peu plus long à lire, pour pas grand chose dans la plupart des cas, mais d'un autre côté, on voit explicitement ce qu'elles font.
Et si ça encombre de façon insupportable votre code, mettez les dans une classe (abstraite ou pas) que vous étendrez...

[Gugelhupf]

Personnellement, ça me prend 15 secondes pour faire générer les getter/setter, la méthode toString, le(s) constructeur(s), les méthodes hashCode/equals avec Eclipse alors je me demande : où est l'intérêt ?

Si tu as la dépendance Lombok dans les dépendances de ton projet, poser une annotation sur une classe te prends moins de 15 secondes, mais ce serait chipoter, ce n'est pas à ce niveau que tu gagnes avec Lombok. Voici deux intérêts :

• Par expérience, j'ai remarqué qu'il était plus dangereux d'utiliser un générateur de code pour les méthodes hashCode/equals que d'utiliser Lombok, en effet ta classe va évoluer mais le développeur ne va pas forcément penser à regénérer les méthodes hashCode/equals lors d'un ajout d'attribut, tandis qu'avec Lombok la question ne se pose pas. Idem pour toString, même si le danger n'y est pas.
• Si ton POJO a 13 attributs, tu vas générer 13 getters et 13 setters, sachant qu'un getter ou un setter basique (non-customisé) prend 3 lignes de code +1 saut de ligne pour représenter la séparation entres les méthodes, tu vas te retrouver avec 104 lignes de code inutiles dans ta classe. Passer par une classe abstraite pour y mettre ses getters et setters ne changera pas le problème de base, la classe abstraite portera par conséquent les attributs aussi.

J'aime bien Lombok, c'est très pratique et je trouve cela dommage qu'il ne soit pas intégré au langage, mais il y a aussi des inconvénients à utiliser ce dernier :

• Lombok est dépendant de la version du compilateur Java que vous utilisez
• Il n'est pas possible de débugger le code Lombok-isé, mais le code généré par Lombok est de toute façon générique
• Il m'est déjà arrivé de rencontrer un cas très particulier où je ne pouvais pas utiliser la dépendance Jackson CSV suite à un conflit avec Lombok

A+

[OButterlin]

Passer par une classe abstraite pour y mettre ses getters et setters ne changera pas le problème de base, la classe abstraite portera par conséquent les attributs aussi.

Ben non, en utilisant la réflexion, on n'a pas besoin.
Je ne dis pas que c'est à retenir mais c'est possible

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
public abstract class AbstractPerson
{
    public String getPrenom()
    {
        try
        {
            Field field = this.getClass().getDeclaredField("prenom");
            field.setAccessible(true);
            return (String)field.get(this);
        }
        catch (Exception e)
        {
            return null;
        }
    }
    public void setPrenom(String prenom)
    {
        try
        {
            Field field = this.getClass().getDeclaredField("prenom");
            field.setAccessible(true);
            field.set(this, prenom);
        }
        catch (Exception e) {}
    }
    public String getNom()
    {
        try
        {
            Field field = this.getClass().getDeclaredField("nom");
            field.setAccessible(true);
            return (String)field.get(this);
        }
        catch (Exception e)
        {
            return null;
        }
    }
    public void setNom(String nom)
    {
        try
        {
            Field field = this.getClass().getDeclaredField("nom");
            field.setAccessible(true);
            field.set(this, nom);
        }
        catch (Exception e) {}
    }
    public Date getDateNaissance()
    {
        try
        {
            Field field = this.getClass().getDeclaredField("dateNaissance");
            field.setAccessible(true);
            return (Date)field.get(this);
        }
        catch (Exception e)
        {
            return null;
        }
    }
    public void setDateNaissance(Date dateNaissance)
    {
        try
        {
            Field field = this.getClass().getDeclaredField("dateNaissance");
            field.setAccessible(true);
            field.set(this, dateNaissance);
        }
        catch (Exception e) {}
    }
 
    public String toString()
    {
        return getPrenom() + " " + getNom() + ", naissance " + getDateNaissance();
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Person extends AbstractPerson
{
    private String prenom;
    private String nom;
    private Date dateNaissance;
 
    public Person(String prenom, String nom, Date dateNaissance)
    {
        super();
        this.prenom = prenom;
        this.nom = nom;
        this.dateNaissance = dateNaissance;
    }
 
}

Pour les avantages que tu cites, soit, mais ça dépend un peu des pratiques utilisées.
Par exemple, je ne génère jamais le hashCode sur l'ensemble des attributs mais uniquement sur celui de la clé primaire (ou ceux si j'utilisais des clés composites).
Idem pour equals.
Pour toString, pareil, je ne mets que les éléments pertinents.

Bref, ce n'est pas que ces annotations n'ont aucun intérêt, je trouve juste que l'essentiel n'est pas là.
Mais ça ne me dérangerait pas que ce soit intégré au langage, qui peut le plus peut le moins

[esperanto]

[B][SIZE=4]La vision autour de ce projet est de réduire les répétitions de blocs de codes dans les nombreuses parties d’une application en les remplaçant par de simples annotations.

Si le code est répétitif, ça veut soit dire qu'il faut le factoriser, soit que les développeurs ont arrêté de réfléchir et prennent la doc du framework au pied de la lettre.
Alors non, jamais je n'utiliserai un outil qui encourage le copier/coller/modifier même si c'est en le remplaçant par une annotation plus courte (et pourquoi pas un préprocesseur de macros pendant qu'on y est?)

Qui plus est, j'utilise très souvent le setter pour monter un flag de modification, je ne pense pas qu'on puisse faire l'équivalent avec l'annotation @setter,

Ouf, au moins un qui s'est dit que si on crée une méthode plutôt que de rendre l'objet public il y avait bien une raison...

• Si ton POJO a 13 attributs, tu vas générer 13 getters et 13 setters,

Si mon objet a 13 attributs déjà je commencerai à me demander s'il y a bien une raison pour que tous soient publiquement consultables et modifiables. J'ai déjà eu affaire à des API basées sur des POJO où pour qu'une fonction extérieure (càd. pas une méthode du POJO lui-même mais dans une autre classe) fonctionne il fallait que deux champs interdépendants n'aient pas de valeur contradictoire, sinon plantage assuré. Si seulement le programmeur avait un peu réfléchi, il aurait au minimum implémenté dans l'un des setters une vérification ou même une modification des champs dépendants. Mais comme aujourd'hui il faut aller vite plutôt que réfléchir...

[Oerys]

Pas fan non plus, comme cela a été dit des outils de génération existent déjà et je trouve ça un peu bizarre de ne pas avoir la main sur le corps des méthodes, comme si c'était l'horreur de lire des getters et des setters

[Pill_S]

Lombok simplifie des choses qui étaient déjà... plutôt simples...

Sans compter les conflits avec les autres bibliothèques de tripatouillage de bytecode, les problèmes de débuggage, les problèmes de reconnaissance par les IDE, et le fait qu'on n'a aucune maitrise sur les différentes implémentations qui découlent de l'action de Lombok, etc...

Vous avez peur que vos equals/hashCode se désynchronisent de votre bean? Y'a HashCodeBuilder et EqualsBuilder, et sa méthode reflectionEquals de Apache commons qui est là depuis longtemps. Idem pour toString. Pas besoin d'ajouter une couche de magie par dessus des trucs qui existent déjà et qui sont diablement efficaces et non-invasifs.

Vous avez la flem' d'écrire des getter / setter? Bon bin là, navré, j'ai pas de solution magique si ce n'est... changez de boulot (le gain de Lombok par rapport à du POJ est quasi inexistant).

Cette lib ne m'a jamais vraiment attirée. Et la pauvreté des fonctionnalité fournies ne va pas me faire changer d'avis.

[Mister Nono]

Marre de toutes ces librairies qui doivent faire le travail à notre place mais nous obligent à travailler pour les utiliser : autant rester sur des standards...

On fini par passer notre temps à apprendre pour faire la même chose qu'avant...

A+

[OButterlin]

Marre de toutes ces librairies qui doivent faire le travail à notre place mais nous obligent à travailler pour les utiliser : autant rester sur des standards...

On fini par passer notre temps à apprendre pour faire la même chose qu'avant...

A+

Oui mais si tu fais à l'ancienne, t'es naze aux yeux des jeunes
Bon, dans l'absolu ça ne m'embête pas plus que ça qu'il y ait des manières différentes de générer ces méthodes mais bon, il y a des choses plus importantes que ces raccourcis.

[JeitEmgie]

Oui mais si tu fais à l'ancienne, t'es naze aux yeux des jeunes

"Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet." Courteline

[Mister Nono]

Oui mais si tu fais à l'ancienne, t'es naze aux yeux des jeunes
Bon, dans l'absolu ça ne m'embête pas plus que ça qu'il y ait des manières différentes de générer ces méthodes mais bon, il y a des choses plus importantes que ces raccourcis.

On trouve des soi-disant professionnels qui connaissent les technologies mais qui sont très limités en algorithmie, conception, force de proposition, écoute, prise en compte du besoin client...

Cela fait des décennies que je lis des titres au sujet de langages qui doivent simplifier la vie des développeurs : fi de tout cela, tout le monde passe son temps à apprendre de nouvelles technologies et tout cela fait perdre plus de temps que celui d'en gagner. Et les article sur de nouveau langages qui font gagner du temps aux développeurs sont toujours là...

Maintenant, il faut aussi savoir sortir du silex et de l'âge de pierre...

A+