Discussion :

[_skip]

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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?

[adiGuba]

Salut,

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

[_skip]

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.

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.

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.

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

[adiGuba]

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

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

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

[_skip]

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.

[_skip]

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.

[fmarot]

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 ?