Discussion :

[thierryler]

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.

[Logan Mauzaize]

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" :

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

[francoisw]

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

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

[natha]

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

[thierryler]

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.

[Logan Mauzaize]

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

[francoisw]

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