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

Bonjour à tous,

Je vous propose un article intitulé "Simplifier le code de vos beans Java à l'aide de Commons Lang, Guava et Lombok".

Synopsis : Un bean classique, représentant un chien par exemple, peut vite peser des centaines de lignes quand on l'équipe avec les méthodes classiques et indispensables (constructeurs, getters, setters, equals, hashCode, toString, compareTo), même s'il possède peu d'attributs. Dans cet article, nous verrons comment mettre un tel cabot au régime et lui faire une beauté à l'aide de Commons Lang, Guava et Lombok. Nous en profiterons pour comparer ces bibliothèques entre elles et avec le code Java habituel, sans oublier celui qu'Eclipse génère.

L'article est disponible ici : http://thierry-leriche-dessirier.dev...-guava-lombok/

Vos retours nous aident à améliorer nos publications. N'hésitez donc pas à commenter cet article sur le forum (à la suite de ce message).

Vous pouvez retrouver mes autres articles ici : http://thierry-leriche-dessirier.dev...#page_articles

Et en particulier un article d'introduction à Guava ici : http://thierry-leriche-dessirier.dev...e-collections/

Bonne lecture.

Très bon article, avec la présentation des différentes méthodes, chacun devrait pouvoir y trouver son compte.

Personnellement la mystification de méthode (absence dans le code source) me paraît très bien justifié dans le cadre de beans simples. D'autant plus s'ils sont bien précisés comme tel (annotation, nom du package, nom de la classe, etc.). Par exemple les règles de codage de mon client mentionne que les classes de POJO soient suffixées par "Bean".

Dépolluer ainsi un code source simple permet de gagner vachement en lisibilité, en temps de codage (essayer un jour de "mesurer" le temps que ca prend en initialisation et en maintenance : ajouter/retirer un champ).
Et c'est encore plus appréciable de ne plus voir/recevoir des codes de equals/hashCode qui ne sont pas "équivalents" :

Citation:

---

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

---

(source).

Bonjour

J'ai apprécié ce comparatif.
J'ai réalisé un framework nommé TEH (pour toString Equals HashCode).
https://github.com/wokier/TEH
En effet, chacun des frameworks avancé a ses avantage et ses défauts.
TEH utilise des annotations, comme lombock, mais sans génération de code, consolide les 3 méthodes (pas seulement 2), et est compatible GWT
J'espère que TEH saura vous convaincre.

Francois Wauquier

@François : tu l'as mis dans quel repo maven ?

A noter qu'un prochain article sera consacré à Lombok et Lombok-pg plus spécifiquement. TEH pourrait y avoir sa place aussi. Il faut que je regarde d'abord.

PS : Il faut que ce soit dans un repo public pour que je puisse légitimement en parler dans l'article.

PS2 : Guava 13 est released donc pense à changer les dépendances de TEH.

Salut,
Merci pour cet article détaillé.
Je crois que je n'inclurais jamais d'outil tel que Lombok car il y a un problème majeur : le contrôle de la qualité du code.
Quand on utilise par exemple Sonar, il y a des checks qui sont effectués, parfois sur le source, parfois sur le code binaire, afin de vérifier certaines règles de qualité. On voit aussi le problème dans tes screenshots avec les variables non-utilisées qui sont en warning.
Je pense que c'est ce genre de raisons qui font que Lombok est peu utilisé et moins le fait que ça fasse "trop de magie".

Citation:

---

Je crois que je n'inclurais jamais d'outil tel que Lombok car il y a un problème majeur : le contrôle de la qualité du code.

---

Oui, je pense aussi que c'est un gros soucis.

Ce n'est pas non plus très "habituel" d'avoir des annotations qui modifient physiquement le code.

Et puis, quid de la documentation sur le code ?...

Pour être franc, perso je ne l'utilise que sur des petits projet et/ou des POCs.

Citation:

---

Envoyé par thierryler

@François : tu l'as mis dans quel repo maven ?

A noter qu'un prochain article sera consacré à Lombok et Lombok-pg plus spécifiquement. TEH pourrait y avoir sa place aussi. Il faut que je regarde d'abord.

PS : Il faut que ce soit dans un repo public pour que je puisse légitimement en parler dans l'article.

PS2 : Guava 13 est released donc pense à changer les dépendances de TEH.

---

Pas encore de repo public, mais un github.
Noté pour guava, je suivrais la version de guava dans la prochaine version de TEH.

Citation:

---

Envoyé par natha

Je crois que je n'inclurais jamais d'outil tel que Lombok car il y a un problème majeur : le contrôle de la qualité du code.
Quand on utilise par exemple Sonar, il y a des checks qui sont effectués, parfois sur le source, parfois sur le code binaire, afin de vérifier certaines règles de qualité. On voit aussi le problème dans tes screenshots avec les variables non-utilisées qui sont en warning.
Je pense que c'est ce genre de raisons qui font que Lombok est peu utilisé et moins le fait que ça fasse "trop de magie".

---

Un bel exemple de la qualité pour la qualité sans comprendre les enjeux. Des codes aussi simples que getter/setter ne vienne que noyer les pourcentages d'erreur. C'est même plutôt un bien qu'ils en soient exclus.

Ensuite les outils utilisés par Sonar proposent TOUS un système d'exclusion. En ciblant correctement, on peut avoir des "bonnes" stats.

Et puisque tu mentionnes Sonar, sache que les POJOs sont rapidement "highlighted" à cause d'un LCOM4 égal au nombre de propriété ... Bref on noie encore le poisson.

A ma connaissance, aucun outil n'assure les règles d'or des méthodes equals/hashCode (en plus de l'équivalence que je mentionnais), par exemple, la transitivité et la réflexivité.

Citation:

---

Pas encore de repo public, mais un github.

---

Dsl dans ce cas, je ne peux pas l'inclure car ça sera trop complexe d'expliquer toute la procédure dans un article. Mais n'hésite pas à me relancer sur le sujet quand il y aura une release maven publique.

Merci pour cet article très clair. Lombok est le système d'annotation que j'aurais voulu avoir à disposition depuis longtemps. Je pense que je vais l'utiliser autant pour mes projets persos que pros.

Personnellement je pense que je vais préférer Commons Lang de Apache ou Guava.
- Premièrement, pour toutes les raisons qui ont été mentionné précédemment (pas de Javadoc, couverture de test même si je suis assez d'accord avec Nemek, etc...).
- Deuxièmement, car l'intégration des librairies Commons Lang ou Guava apporte bien plus de fonctionnalités supplémentaires que la seule simplification des Beans.

en tout cas, très bon article :ccool:
C'est alléchant ce "@Data" :mouarf:

Citation:

---

Envoyé par Robin56

- Premièrement, pour toutes les raisons qui ont été mentionné précédemment (pas de Javadoc, couverture de test même si je suis assez d'accord avec Nemek, etc...).

---

J'avais pas pensé que la couverture des getter/setter/hashCode/equals venait également pourrir les métriques de la couverture de code ...

Citation:

---

Envoyé par Robin56

- Deuxièmement, car l'intégration des librairies Commons Lang ou Guava apporte bien plus de fonctionnalités supplémentaires que la seule simplification des Beans.

---

Surtout que beaucoup de framework (ex: RichFaces, Spring) vont également apportés ces dépendances. Alors autant en profiter !

Bonjour.

merci pour cet article.
J'ai expérimenté lombok et je le trouve plutôt bien.

Je ne pense pas que sa faible pénétration soit du à son côté "magique"
les raisons qui chez moi font qu'il n'est pas utilisé sont
- sa version 0.x qui est conciédré par les décideur comme la marque d'un risque trop élevé.
- l'incopréhention des nons développeurs qui ont le pouvoir de décider sur le runtime.jar. beaucoup mors de la présentation de la lib ont compris que lombok embarquait une par interprété (d'où la nécécité d'un runtime)
- l'absence de preuve de sont efficacité à l'exécution.

pour ma part j'ai test lonmbok sous camel
une simple classe comme Dog dont le code ne contient que la cdéfinition du nom de la classe et des membres.
l'ajout de l'annotation @data. combiné avec les annotation jaxb et bindy
soit donc 1 + 3 lignes pour la classe (annotation jaxb, annotation bindy annotation lombok)
1 + 1 lignes par membre (annotation bindy)

et on obtient avec un simple fichier xml de 8 lignes deux routes camels qui reçoivent par le protocole de son choix soit un fichier xml soit un fichier csv et qui produisent sur le protocole de sont choix le contenus convertit.

J'ai trouvé ça très céduisant.
Mais face aux arguments sur la jeunesse le manque de visibilité sur la pérénité de la libraire les gains pour le codeur ont fait long feu

A+JYT

Dans le cadre d'une présentation que je vais faire tourner à la rentrer dans différents JUG, je vais faire un slide "Pour ou contre Lombok".

D'après vous, quels sont les points importants qui devraient figurer dans ce slide ?

Merci.

Je pense que tu en as déjà quelques éléments:

Contre:

• C'est magique ...
• Le principe de modifier la configuration du compilateur
• On peut pas débugger
• On peut pas documenter
• Ralenti la compilation (?)

Pour:

• C'est magique !
• Ne pourri pas le code avec du code sans intérêt
• Ne pourri pas les statistiques de couverture de test avec du code sans intérêt
• Ne pourri pas les statistiques d'analyse de code avec du code sans intérêt
• Fait gagner beaucoup de temps à l'écriture
• Idéal pour le prototypage / RAD

Bon ok, les points sur les stats sont falacieux car il suffit d'utiliser les systèmes d'exclusion fourni par ces APIs ...

La liste me convient bien oui. J'ajouterais en contre le fait de devoir installer un plugin au sein de l'IDE là où les 2 autres méthodes ne nécessitent que l'ajout d'une librairie.

@francoisw : Si tu nous met tout ça dans un repo Maven public et que tu documentes un peu, je pourrai intégrer ta lib comme j'avais fais dans cet article avec l’excellent MoteurCsv : http://thierry-leriche-dessirier.dev...sv-5-min/#L6-C

Citation:

---

Ralenti la compilation (?)

---

Perso, durant mes essais, ça a été invisible

Contre:

• C'est magique ... <= pour moi ce n'est pas un contre
• Le principe de modifier la configuration du compilateur
• On peut pas débugger
• On peut pas documenter
• Ralenti la compilation (?)

d'un point de vu de décideur et pas de codeur

• Pas de visibilité sur la pérennité de la lib
• N'a pas fait ses preuves
• Pas dans le giron d'un groupe open source comme apache.

Pour:

• C'est magique !
• Ne pourri pas le code avec du code sans intérêt
• Ne pourri pas les statistiques de couverture de test avec du code sans intérêt
• Ne pourri pas les statistiques d'analyse de code avec du code sans intérêt
• Fait gagner beaucoup de temps à l'écriture
• Idéal pour le prototypage / RAD
  
• se combine bien avec d'autre annotations