Prise en main de la bibliothèque Lombok pour simplifier l'écriture des classes Java,un tutoriel de Joan David

Modérateur

Le 14/09/2017 à 12:13

Ce genre d'outil me laisse pantois...
Les affirmations du genre "le getter/setter, hashCode() etc... dont l'implémentation ne nécessite normalement aucune réflexion particulière" n'engagent que l'auteur.

Chez nous, le hashCode est généré en fonction de la clé primaire pour bien des classes (ou super.hashCode() quand elle est nulle)
La méthode toString() ne contient que des informations utiles pour voir sur quoi on est dans le debug, si on devait se taper les 250 attributs des grosses classes, bonjour la lisibilité !
La méthode equals() est également dépendante de la clé primaire dans certains cas...
Le setter est souvent utilisé pour positionner un flag de changement de valeur...
Et qu'en est-il au niveau du debug si le source ne contient pas les méthodes ?

Bref, si le but est d'en faire un minimum, soit, c'est l'outil qu'il faut

2

0

GordonFreeman

Membre éclairé

Le 14/09/2017 à 16:00

Envoyé par ThomasEscolan

Bonjour, merci pour cette synthèse !
Une petite remarque concernant les erreurs de copier-coller sur les logger factories. Vos ennuis viennent, je pense, d'une mauvaise compréhension du pattern singleton :
La variable "log" n'a pas besoin d'être statique, puisqu'une seule instance est produite pour chaque "clef". Du coup vous pouvez utiliser "this" et éviter ainsi les confusions :

Code :

Sélectionner tout

private final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(this.getClass());

Sérieux ? Ben j'aurais au moins appris quelque chose aujourd'hui. Merci pour l'info

Concernant Lombok, de manière générale, je suis aussi un peu dubitatif face à ce genre d'outils. Pour moi ça amène plus de risque que d'avantage..

Générer des getters/setters mon IDE le fait très bien. Je veux dire par là que c'est vraiment pas un gros gain en terme de temps de travail. De plus, en cas de débogage, je pense que cela peux amener de la confusion dans certains cas (p. ex. s'il y a déjà X proxies sur la classe ou des aspects sur la méthode).

De plus, à mon sens, equals(), hashCode() ou toString() sont tout sauf des méthodes anodines qui peuvent forcément être générées de manière uniforme. et encore une fois, le fait de les générer via l'IDE permet un meilleur contrôle sur le code.

En pratique, je préfère limiter la génération/l'injection de code au élément qui présente un intérêt majeur.

Encore une fois c'est un avis général, probablement que dans certains cas ça peut amener une plus-value.

1

0

Pill_S

Membre expert

Le 20/09/2017 à 13:30

Envoyé par ThomasEscolan

La variable "log" n'a pas besoin d'être statique, puisqu'une seule instance est produite pour chaque "clef". Du coup vous pouvez utiliser "this" et éviter ainsi les confusions :

Pas d'accord, dans le cas d'une hiérarchie de classes, getClass() va retourner le type concret de la classe, et pas le type courant. Donc, on se retrouve à logger sous le nom de class "MyClass" alors que le code est localisé dans "AbstractMyClass"

Alors ce n'est pas nécessairement un problème, mais je pense que personne ne trouvera normal de voir que MyClass log des erreurs et de ne pas retrouver le code correspondant...

PS: et aussi, comment utiliser ce logger dans un contexte statique (certes rare, mais loin d'être inutilisé)?

Sinon, pour le reste de Lombok, personnellement je n'y vois aucun intérêt. ça facilite la gestion de code qui est de toute façon plutôt facile à écrire et comprendre, en ajoutant une couche de magie qui posera rapidement plus de problème qu'elle n'en résoud... et si il faut en plus installer des plugins pour avoir une chance que l'IDE soit content.... bah voilà quoi, perso ce n'est pas une option

1

0

Pill_S

Membre expert

Le 19/02/2018 à 13:42

Envoyé par ThomasEscolan

Dans ce cas, je suggère d'utiliser l'annotation @Slf4j ou une de ses cousines, fournies par... Lombok ;-)

Ou alors, méthode que je viens de découvrir (!) dans la doc slf4j: https://www.slf4j.org/faq.html#declaration_pattern

Dès Java 7:

Code :

Sélectionner tout

1
2
final static Logger logger = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());

Tadaaam

1

0

ThomasEscolan

Membre habitué

Le 14/09/2017 à 12:38

Toutes les personnalisations sont prévues (champs à utiliser dans tel ou tel cas). Les méthodes implémentées manuellement ne sont pas surchargées. Bref, quand on veut bosser, Lombok ne l'empêche pas.
L'ESSAYER, c'est l'adopter.

Envoyé par OButterlin

...
Chez nous, le hashCode est généré en fonction de la clé primaire pour bien des classes (ou super.hashCode() quand elle est nulle)
La méthode toString() ne contient que des informations utiles pour voir sur quoi on est dans le debug, si on devait se taper les 250 attributs des grosses classes, bonjour la lisibilité !
La méthode equals() est également dépendante de la clé primaire dans certains cas...
Le setter est souvent utilisé pour positionner un flag de changement de valeur...
Et qu'en est-il au niveau du debug si le source ne contient pas les méthodes ?
...

0

GordonFreeman

Membre éclairé

Le 20/09/2017 à 16:18

Envoyé par Pill_S

Pas d'accord, dans le cas d'une hiérarchie de classes, getClass() va retourner le type concret de la classe, et pas le type courant. Donc, on se retrouve à logger sous le nom de class "MyClass" alors que le code est localisé dans "AbstractMyClass"

Alors ce n'est pas nécessairement un problème, mais je pense que personne ne trouvera normal de voir que MyClass log des erreurs et de ne pas retrouver le code correspondant...

PS: et aussi, comment utiliser ce logger dans un contexte statique (certes rare, mais loin d'être inutilisé)?

Sinon, pour le reste de Lombok, personnellement je n'y vois aucun intérêt. ça facilite la gestion de code qui est de toute façon plutôt facile à écrire et comprendre, en ajoutant une couche de magie qui posera rapidement plus de problème qu'elle n'en résoud... et si il faut en plus installer des plugins pour avoir une chance que l'IDE soit content.... bah voilà quoi, perso ce n'est pas une option

De déclarer les logger de la manière suivante :
private final Logger logger = LoggerFactory.getLogger(MyClass.class);
private final Logger logger = LoggerFactory.getLogger(MyAbstractClass.class);

Du coup plus de static pour les classes non-statiques et plus de problème de logger qui ne 'logguent' pas la bonne classe.
Pour le coup du context statique ben ma foi logger static...

Mais on s'écarte du sujet original

0

Pill_S

Membre expert

Le 20/09/2017 à 16:21

Envoyé par GordonFreeman

De déclarer les logger de la manière suivante :
private final Logger logger = LoggerFactory.getLogger(MyClass.class);
private final Logger logger = LoggerFactory.getLogger(MyAbstractClass.class);

... ce qui n'évite du coup plus les problème de copier-coller...

Envoyé par GordonFreeman

Mais on s'écarte du sujet original

Certes

0

ThomasEscolan

Membre habitué

Le 21/09/2017 à 11:18

Envoyé par Pill_S

Pas d'accord, dans le cas d'une hiérarchie de classes, getClass() va retourner le type concret de la classe, et pas le type courant. Donc, on se retrouve à logger sous le nom de class "MyClass" alors que le code est localisé dans "AbstractMyClass"

Alors ce n'est pas nécessairement un problème, mais je pense que personne ne trouvera normal de voir que MyClass log des erreurs et de ne pas retrouver le code correspondant...

PS: et aussi, comment utiliser ce logger dans un contexte statique (certes rare, mais loin d'être inutilisé)?

Dans ce cas, je suggère d'utiliser l'annotation @Slf4j ou une de ses cousines, fournies par... Lombok ;-)

0

thierryler

Rédacteur

Le 19/10/2017 à 15:36

Pour la forme, un viel article dans le même goût : Simplifier le code de vos beans Java à l'aide de Commons Lang, Guava et Lombok
http://thierry-leriche-dessirier.dev...-guava-lombok/

Ce qui est intéressant avec Lombok, de mon point de vue, c'est que si tu as besoin d'un bean standard avec le même comportement que les méthodes générées par Eclipse (ce qui est certainement le cas dans la plupart de nos beans) alors Lombok va radicalement simplifier les beans. Et si tu as besoin d'un comportement spécifique à un endroit donné, alors tu peux toujours surcharger la méthode en question car Lombok ne réécrit pas dans ce cas.

L'autre truc que j'adore avec Lombok, c'est que tout est généré. Ca veut dire que tu n'as plus à craindre des getter/setter ou autres méthodes écrites à l'aide de copié-collé hasardeux. Le nombre de bug qui vennaient en fait d'un mauvais copié -collé dans un getter et que j'ai mis 3 jours à trouver... Au moins là je sais que c'est fiable.

Attention par contre, car lombok "instrumente" votre code. Vous ne pouvez par exemple pas avoir lombok et aspectj car ils vont s'écraser mutuellement (bug ouvert chez les 2 lib).

0

ThomasEscolan

Membre habitué

Le 14/09/2017 à 11:09

Bonjour, merci pour cette synthèse !
Une petite remarque concernant les erreurs de copier-coller sur les logger factories. Vos ennuis viennent, je pense, d'une mauvaise compréhension du pattern singleton :
La variable "log" n'a pas besoin d'être statique, puisqu'une seule instance est produite pour chaque "clef". Du coup vous pouvez utiliser "this" et éviter ainsi les confusions :

Code :

Sélectionner tout

private final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(this.getClass());

0

1

Identifiez-vous

Créer un compte

Prise en main de la bibliothèque Lombok pour simplifier l'écriture des classes Java,

Un tutoriel de Joan David

Identifiant
Mot de passe

Mot de passe oublié ?

Identifiez-vous

Créer un compte

Prise en main de la bibliothèque Lombok pour simplifier l'écriture des classes Java, Un tutoriel de Joan David

Prise en main de la bibliothèque Lombok pour simplifier l'écriture des classes Java,

Un tutoriel de Joan David