Lombok : Que pensez-vous de cette librairie Java qui génère du code invisible
Et utilisable à partir d'annotations ?
Le 2010-01-11 14:51:12, par _skip, Expert éminent
Bonjour,
Au hasard je suis tombé sur une article de blog parlant d'un framework du nom de Lombok, celui-ci permettrait, à l'aide d'annotations, de générer certaines méthodes au lancement :
Ainsi un POJO simple de ce genre :
pourrait s'écrire
Ce qui peut simplifier considérablement certains objets anémiques qui sont comparables à de simples structures C++.
Vous avez au menu d'autres annotations :
Resterait à savoir si c'est utilisable et ce que ça implique au niveau support IDE et tout ça.
Donc est-ce que quelqu'un s'est déjà penché sur la question?
Au hasard je suis tombé sur une article de blog parlant d'un framework du nom de Lombok, celui-ci permettrait, à l'aide d'annotations, de générer certaines méthodes au lancement :
Ainsi un POJO simple de ce genre :
Code : |
1 2 3 4 5 6 7 8 9 10 11 12 | public class Person { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } } |
pourrait s'écrire
Code : |
1 2 3 4 5 6 7 8 | import org.lombok.Getter; import org.lombok.Setter; public class Person { @Getter @Setter private String name; } |
Vous avez au menu d'autres annotations :
Code : |
1 2 3 4 5 6 7 8 | * @Getter and @Setter: create getters and setters for your fields * @EqualsAndHashCode: implements equals() and hashCode() * @ToString: implements toString() * @Data: uses the four previous features * @Cleanup: closes your stream * @Synchronized: synchronize on objects * @SneakyThrows: throws exceptions |
Resterait à savoir si c'est utilisable et ce que ça implique au niveau support IDE et tout ça.
Donc est-ce que quelqu'un s'est déjà penché sur la question?
-
_skipExpert éminentSans vouloir entrer dans le débat religieux, au départ j'étais absolument contre la réflexion, l'injection, l'AOP et tout ça... C'est devenu tellement courant maintenant que je me suis adapté.
Cette solution m'intéresse justement parce qu'elle est basée sur de la génération de code plutôt que sur de la magie noire comme c'est le cas de (trop) nombreux frameworks.
Je conçois qu'on puisse être contre, moi tout ce qui peut améliorer ma productivité et réduire la plomberie m'intéresse. Ca peut ne pas plaire à tout le monde, c'est clair.le 13/01/2010 à 10:43 -
adiGubaExpert éminent séniorSalut,
Il y a le support du compilateur d'eclipse via un plugin, et c'est automatiquement pris en compte par javac 1.6 du moment que la librairie est dans le classpath (via le processeur d'annotation), donc cela devrait être compatible avec NetBeans ou d'autres EDI qui utilisent javac...
A noter que la librairie n'est utile que lors de la compilation.
Par contre d'un point de vue idéologique ce n'est pas très correct car les annotations ne devrait pas à modifier le code des classes sur lesquelles ont les utilise, ce qui est loin d'être le cas ici...
En clair en désactivant le processeur d'annotation plus rien ne marche
Dans la plupart des cas on peut utiliser la génération automatique de code par l'EDI (@Getter, @Setter, @EqualsAndHashCode et @ToString). Le seul intérêt consiste alors simplement à "cacher" cela dans le code...
De mon point de vue, les plus intéressants restent @Cleanup et @SneakyThrows qui couvre des cas bien verbeux, alors que l'intérêt de @Synchronized est vraiment minime
A noter que Java 7 proposera l'équivalent de @Cleanup via les blocs ARM.
a++le 11/01/2010 à 17:36 -
_skipExpert éminentJustement, cela évite sans doute le recours à la reflection et aux outils de trifouillage de bytecode à la cglib.
Possible mais on peut dire la même chose de tout ce qui est AOP dans ce cas. Les annotations ne serviraient alors qu'aux frameworks basés sur la réflexion ou l'injection. D'ailleurs pour parler d'idéologie, perso je trouve ça moins moche que l'injection en soi.
C'est juste mais ça reste tout de même de la plomberie inutile qui peut, dans une classe POJO anémique, multiplier par 10 le nombre de lignes de code. Ce qui m'a toujours tué en java, c'est de devoir documenter
-un membre de classe
-la méthode get
-le @param de la méthode get
-la méthode set
-le @return de la méthode set
Et si tu veux renommer ta propriété, ben cool c'est la fête.
Mais là je pense que ceci ne m'aidera pas car je doute que javadoc soit capable de gérer quoi que ce soit de ce style.
Oui et c'est pour moi l'un des ajouts majeurs avec les simplifications de catch.
Merci A++le 11/01/2010 à 18:45 -
adiGubaExpert éminent séniorC'est justement pour cela que je le précisais
C'est comme cela : les annotations ne doivent que marquer le code et non pas en modifier le résultat de la compilation de la classe en elle même...
Je dis juste qu'il serait préférable d'avoir une vrai gestion des property, avec une compatibilité avec les getter/setter et une syntaxe complète plutôt qu'un "hack" basé sur les annotations...
a++le 11/01/2010 à 21:23 -
_skipExpert éminentJe serai le premier à être d'accord, malheureusement elles ont été balayées en java 7. Dommage je trouve car c'est dans 90% des cas de la pure plomberie.le 11/01/2010 à 21:41
-
_skipExpert éminentUne petite vidéo exemple sous netbeans :
http://slx.sun.com/1179276153
Observez l'explorateur de membres en bas à droite de l'écran qui change lorsque le mec ajoute @Data devant la classe.le 12/01/2010 à 9:58 -
ZeRevoMembre avertiXDoclet ne fait-il pas la même chose ?le 12/01/2010 à 21:54
-
HayaxxMembre du ClubIntéressant ! J'avoue que les classes a rallonge pleines de getters/setters ont tendance à m'énerver un peu...
Vivement le même genre de choses pour les autres languages !le 12/01/2010 à 22:14 -
dingothMembre expérimentéAvec Eclipse :
Génération de getters/setters : [Alt + s] + r (trois touches + 2 clics après)
Génération de toString : [Alt + s] + s (trois touches + 2 clics après)
Génération de hashCode + equals : [Alt + s] + h (trois touches + 2 clics après)
Génération automatique de la documentation disponible dans les propriétés du projet ou d'Eclipse.
Avec Lombok:
Génération de getters/setters : "@Get" + [ctrl + espace] + enter + "@Set" + [ctrl + espace] + enter
Génération de toString : "@ToStr" + [ctrl + espace]
Génération de hashCode : "@EqA" + [ctrl + espace]
Documentation apparemment automatique.
Franchement... Ca vaut la peine d'utiliser une librairie pour ça ?
Je préfère attendre la gestion native des properties dans Java.le 12/01/2010 à 22:36 -
fmarotNouveau membre du ClubAh ben ce thread tombe bien, merci _Skip
Des collegues ont récemment introduit Lombock sur une partie du projet: une API qui doit etre rendue publique. Or, qui dit "publique" dit "Javadoc" ! Mais commet créer la javadoc avec Lombock ?!
Dans le code, les champs annotés @getter et @setter étaient documentés. Mais lors de la génération de la Javadoc, les méthodes getXXX et setXXX n'apparaissaient pas. Normal...
On a alors généré le code source délomboké (en utilisant l'outil "delombok". Les méthodes getXXX et setXXX apparaissent bien dans la javadoc apres ca, mais pas les commentaires positionnés sur les champs privés !
Là, 2 solutions:
- soit générer la javadoc paramétrée pour afficher les champs "private" mais pour une API publique ca craint...
- soit inclure en début de la javadoc public d'une classe un tableau (issu de la javadoc générée en affichant les champs privés) récapitulant les champs privés annotés get/set avec leur documentation.
C'est cette derniere solution qui a été retenue. Couplée à un processus manuel, je vous raconte pas comme on va s'amuser si l'API change souvent !
Avez vous une solution à la génération de la javadoc des champs annotés avec Lombok ?le 12/01/2010 à 23:13