IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Lombok : Que pensez-vous de cette librairie Java qui génère du code invisible
Et utilisable à partir d'annotations ?

Le , par _skip

75PARTAGES

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

Code : Sélectionner tout
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 : Sélectionner tout
1
2
3
4
5
6
7
8
import org.lombok.Getter;
import org.lombok.Setter;

public class Person {

  @Getter @Setter
  private String name;
}
Ce qui peut simplifier considérablement certains objets anémiques qui sont comparables à de simples structures C++.

Vous avez au menu d'autres annotations :

Code : Sélectionner tout
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?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de _skip
Expert éminent https://www.developpez.com
Le 13/01/2010 à 10:43
Sans 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.
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 11/01/2010 à 17:36
Salut,

Citation Envoyé par _skip Voir le message
Resterait à savoir si c'est utilisable et ce que ça implique au niveau support IDE et tout ça.
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++
0  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 11/01/2010 à 18:45
Citation Envoyé par adiGuba Voir le message

A noter que la librairie n'est utile que lors de la compilation.
Justement, cela évite sans doute le recours à la reflection et aux outils de trifouillage de bytecode à la cglib.

Citation Envoyé par adiGuba Voir le message

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

Citation Envoyé par adiGuba Voir le message

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

Citation Envoyé par adiGuba Voir le message

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.
Oui et c'est pour moi l'un des ajouts majeurs avec les simplifications de catch.
Merci A++
0  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 11/01/2010 à 21:23
Citation Envoyé par _skip Voir le message
Justement, cela évite sans doute le recours à la reflection et aux outils de trifouillage de bytecode à la cglib.
C'est justement pour cela que je le précisais

Citation Envoyé par _skip Voir le message
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 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...

Citation Envoyé par _skip Voir le message
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.
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++
0  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 11/01/2010 à 21:41
Citation Envoyé par adiGuba Voir le message

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++
Je 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.
0  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 12/01/2010 à 9:58
Une 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.
0  0 
Avatar de ZeRevo
Membre averti https://www.developpez.com
Le 12/01/2010 à 21:54
XDoclet ne fait-il pas la même chose ?
0  0 
Avatar de Hayaxx
Membre du Club https://www.developpez.com
Le 12/01/2010 à 22:14
Inté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 !
0  0 
Avatar de dingoth
Membre expérimenté https://www.developpez.com
Le 12/01/2010 à 22:36
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.
0  0 
Avatar de fmarot
Nouveau membre du Club https://www.developpez.com
Le 12/01/2010 à 23:13
Ah 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 ?
0  0