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

Citation:

---

Envoyé par thierryler

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

---

chez moi aussi

Bonjour,

Merci également pour cet article qui est très bon.

Citation:

---

On doit ensuite faire un refresh (touche F5) dans Eclipse pour faire apparaitre Guava (et ses dépendances) dans la liste des bibliothèques référencées.

---

Pour la première fois où cette phrase apparait : On doit ensuite faire un refresh (touche F5) dans Eclipse pour faire apparaitre Apache Commons Lang (et ses dépendances) dans la liste des bibliothèques référencées.

Citation:

---

Envoyé par Nemek

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

---

J'ai travaillé sur des projets où les entités censées contenir uniquement des getters/setters étaient ignorées des analyses SONAR. Par curiosité j'ai enlevé le filtre et quelle ne fut pas ma surprise d'avoir des dépendances cycliques de packages, des dizaines de violations supplémentaires, etc.
C'est toujours compliqué de trouver le juste milieux.

Salut a tous
bon bah je vais passer pour un troll, mais pourquoi ne pas simplifier votre code en utilisant groovy et gmaven :pastaper:
La dernière fois que j'ai utilisé lombok intellij ne voyait pas la génération des méthodes au runtime, et les equals et hashcode étaient peu customisable.

En tous cas merci pour l'article

Merci pour cet article. Je découvre plein de choses d'un coup...

Le seul truc qui me dérange est le fait de devoir modifier l'IDE avec Lombok. Sinon c'est clair que ça peut être un sacré gain de temps...

Citation:

---

Envoyé par dark.jabberwock

Le seul truc qui me dérange est le fait de devoir modifier l'IDE avec Lombok. Sinon c'est clair que ça peut être un sacré gain de temps...

---

Je ne sais pas si l'on peut parler de gain de temps car un "Generate getters and setters" est assez rapide d'origine. Je parlerais plutôt de gain de lisibilité et de qualité de code.

En fait Robin56 je pensais à un gain de temps si l'on utilise l'annotation @Data. Car au niveau d'Eclipse même avec les raccourcis clavier, c'est plus court d'écrire 5 lettres en annotations que de générer via l'IDE les différents éléments générés par @Data. Par contre le "sacré gain de temps" est largement exagéré de ma part j'en convient.

Après effectivement c'est surtout un gain de lisibilité et pour moi une certaine qualité de code notamment au niveau equals et hashCode.

Réflexion à part, en pensant aux métriques de Sonar (je ne connais que peu le paramétrage de l'outil), on nettoie peut être un peu la partie nombre de ligne de code et pourcentage de commentaire. A moins que pour ces informations, on puisse également exclure les classes de certaines vérifications. Là dessus qu'en pensez-vous ?

Citation:

---

Envoyé par natha

J'ai travaillé sur des projets où les entités censées contenir uniquement des getters/setters étaient ignorées des analyses SONAR. Par curiosité j'ai enlevé le filtre et quelle ne fut pas ma surprise d'avoir des dépendances cycliques de packages, des dizaines de violations supplémentaires, etc.
C'est toujours compliqué de trouver le juste milieux.

---

Je te l'accorde ! D'ailleurs à l'inverse sur mes projets j'ai des classes bêtes et méchantes (type utilitaire) qui sont marqués en Hot Spot (pas sûr du nom). De même, les classes un peu critique au sens de l'analyse statique (beaucoup de code) remonte rapidement alors que d'autres classes avec moins code mais très critique vont rester dans le bas du tableau, derrière des POJO, parce qu'elles ont peu de code.

Cependant, dans ton cas, il semble surtout que ce soit un problème d'identification des exclusions. Je suggère fortement aux architectes/concepteurs/dev leader de définir clairement des règles aussi bien de codage que d'organisation des packages ou des règles précises de nommage.
Ca permet dans tous les cas à quelqu'un de comprendre là où il se trouve (lors de la navigation / recherche) et où il doit chercher dans le code.

Autre point, certaines règles ne devraient pas avoir d'exclusion (en tout cas, je ne vois pas de raison), et je pense dans ton cas, à l'analyse des dépendances.

Enfin, cela me donne une idée pas si mal, inclure des analyses spécifiques pour ce qui a été exclu. Je ne sais pas si cela est possible avec Sonar ... Par exemple, vérifier qu'il s'agit de simple POJO.

Citation:

---

Envoyé par Robin56

Je ne sais pas si l'on peut parler de gain de temps car un "Generate getters and setters" est assez rapide d'origine. Je parlerais plutôt de gain de lisibilité et de qualité de code.

---

En maintenance, ca fait toujours gagner pas mal de temps et éviter des erreurs bêtes comme supprimer des getter/setter mais pas l'attribut et pour le couple equals/hashCode j'en parle même pas !

Citation:

---

Envoyé par dark.jabberwock

Réflexion à part, en pensant aux métriques de Sonar (je ne connais que peu le paramétrage de l'outil), on nettoie peut être un peu la partie nombre de ligne de code et pourcentage de commentaire. A moins que pour ces informations, on puisse également exclure les classes de certaines vérifications. Là dessus qu'en pensez-vous ?

---

Vu qu'il n'y a pas de code, ces métriques ne sont pas "impactées". Comme je le mentionnai ca ne peut qu'augmenter la justesse des métriques.
Exemple, 10 erreurs sur 100 lignes utiles ou sur 125 dont 25 inutiles, ca donne 10% ou 8% d'erreur. Si on considère qu'il y a beaucoup de POJO, surtout avec des framework comme Struts (Forms) / JSF (Backing bean) / JPA (Persistent class) / J2EE (EJB), il doit y avoir un paquet de lignes de codes non critiques.

Bonjour

J'ai un test avec NetBeans sa ne fonctionne pas (j'ai pas trouvé de plugiin) puis dans mon cas j'utilisé un projet Maven sur NetBeans ? (a 1er vu je peu pas utilisé Lombok !!)
Serai t'il possible d'utilisé Lombok avec des entité JPA ?

Merci

Citation:

---

Envoyé par geforce

Bonjour

J'ai un test avec NetBeans sa ne fonctionne pas (j'ai pas trouvé de plugiin) puis dans mon cas j'utilisé un projet Maven sur NetBeans ? (a 1er vu je peu pas utilisé Lombok !!)
Serai t'il possible d'utilisé Lombok avec des entité JPA ?

Merci

---

Je pense qu'il n'y a pas de pb je l'ai utilisé avec les annotations Jaxb et Bindy alors pourquoi pas les annotation JPA.

A+JYT

Le plugin NetBeans est inclus dans le Jar de Lombok. Il suffit de double cliquer dessus après l'avoir téléchargé.

Bonjour thierryler et sekaijin

Ci-dessous le message d'erreur que j'ai dans mon IDE (je les testé sur deux pc différant et c'est la même chose).

Pièce jointe 153929

de plus dans cette classe beans voir la fenêtre Navigator je n'ai pas les getteur et setteur et ..... avec mon utilisation de @Data. de plus même dans l'éditeur je n'est pas accès au getteur et setteur... :aie:

NB: j'utilise Netbeans 8.0. et le Jar lombok-0.11.0 est bien chargé.

Déjà, as-tu bien installé le plugin ? Pour cela télécharge le jar/zip de Lombok et double-clic dessus.

Dans Eclipse j'ai aussi des soucis avec @Data

Citation:

---

Envoyé par thierryler

Déjà, as-tu bien installé le plugin ? Pour cela télécharge le jar/zip de Lombok et double-clic dessus.

Dans Eclipse j'ai aussi des soucis avec @Data

---

Oui j'ai fait comme tu ma dit sur la Jar de Lombok (je les récupéré avec Maven), mais rien qui se passe (pas d’installation du plugin selon moi).
Pièce jointe 154084

un double click n'est peut-être pas la bonne façon de faire.

en effet un fichier *.jar n'est pas exécutable.
Il faut pour cela qu'il soit associé à un exécutable Java ce qui n'est pas toujour le cas.

sous windows il faut associer *.jar à "C:\Program Files\Java\jre1.6.0_01\bin\java.exe" -jar "%1" %*
Mais sous sevent il n'est plus possible via l'interface graphique d'ajouter un verbe dans la liste des commandes associé à un type de fichier.

du coup les seules solution sont de remplacer l'action
ou passer par regedit pour ajouter une commande.

essais en ligne de commande
java.exe -jar Lombok.jar

A+JYT

Quand je double-clic dessus, sous Windows 7, ça lance l'interface d'installation de Lombok. Celle-ci me demande dans quel Eclipse je veux installer...

C'est parce que par défaut sous windows7 la commande associé au fichier *.jar est java.exe -jar %1 %
mais ce n'est pas toujours le cas

A+JYT

Bonjour à tous,

Bien quand je Click avec mon Windows 7 directement sur la lombok-0.11.0.jar (je ne passe pas par mon IDE NetBeans) j'ai l’interface qui se lance, mais ne me donne pas le choix d'installer le plugin sur NetBeans il y que le choix d'Eclipse.

Y t'il le plugin pour NetBeans ?

Merci