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.

[ZeRevo]

XDoclet ne fait-il pas la même chose ?

[Hayaxx]

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 !

[dingoth]

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.

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

[Baptiste Wicht]

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 problème n'est pas de les générer mais de ne plus les voir polluer son code. Si c'est juste pour les générer, effectivement Lombok ne sert à rien, mais le code avec Lombok sera moins lourd à lire. Par contre, comme l'a dit dit adiGuba, ce n'est pas la fonction des annotations.

[dingoth]

Ce n'est pas de la pollution. Traiter le code normal de Java de polluant, c'est forcer l'esprit des développeurs à chercher des alternatives à tout prix alors que Java n'est pas conçu pour être moins verbeux.

Le code est verbeux, j'en conviens, mais polluant ? J'ai quelques objets DTO de 30 champs et plus, et il reste toujours facile de s'y retrouver. Ctrl + f est votre ami dans 99% des cas.

Si on veut vraiment faire des économies de code, il existe bien des frameworks de properties où les membres peuvent être écris comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class Personne {
  public final Property<String> nom = new Property<String>("nom");
 
  public final Property<Integer> age = new Property<Integer>("age");
}
 
Personne p = new Personne();
p.nom.set("Jean-Pierre");
p.age.set(32);

En terme de rapport fonctionnalité / économie de code, on a un bon rapport, là, non ? Pas mal de fonctionnalités y sont ajoutées également, telles les contraintes, les listeners, etc. et surtout une seule documentation.

Je suis résolument contre le détournement des annotations dans ce contexte. Les annotations permettent l'ajout de fonctionnalités, à côté du code, pas du code tout court. Selon moi, ce genre de framework n'est pas pour les bons programmeurs paresseux, mais pour les mauvais programmeurs paresseux car ils oublient qu'ils programment en Java et pas dans un autre langage. Si d'autres langages supportent les properties nativement, qu'ils les utilisent. Pour l'instant, Java ne le fait pas et en faire une mauvaise émulation est pire qu'attendre la solution native.

[_skip]

Hey, y'a eu du mouvement ici!

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 ?

Ben je plussoie mon compatriote ci-dessus. En fait le problème est pas vraiment l'écriture de ce code mais sa simple présence. De plus je trouve que c'est un gain de lisibilité de voir immédiatement qu'une propriété est publique ou non sans avoir besoin de vérifier si il y a un getter/setter dans la masse.

Par exemple, lorsque j'écrivais des managed bean pour JSF, je me retrouvais avec parfois des classes java contenant 20-30 propriétés liées à des formulaires, plus quelques autres membres non publics nécessaires au fonctionnement de la classe.

En gros je me retrouve avec 40-60 méthodes get/set qui prennent une place complètement insensée. Si je veux modifier le nom d'une propriété, sous netbeans je peux m'amuser à aller renommer la méthode, le commentaire, le paramètre du setter, ouais quand même c'était un peu lourd.

Je préfère attendre la gestion native des properties dans Java.

Ce serait en effet préférable d'avoir cette gestion niveau langage, j'ai juste peur qu'on puisse l'attendre encore vachement longtemps.

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 ?

C'est aussi le point qui a tendance m'inquiéter, ici dans nos process on doit documenter toute l'interface publique. Et parfois il est aussi nécessaire d'indiquer une chose ou deux, comme par exemple faire référence à des constantes ou indiquer quelle est la valeur par défaut. Il est aussi confortable de voir une doc s'afficher dans la fenêtre d'autocomplétion de son IDE.

J'ai pensé aussi à delombok, malheureusement ça ne génère pas de commentaire. En fait pour l'instant c'est le point qui me retiens. J'ai ouvert un topic sur le fil de discussion de lombok à ce sujet :

http://groups.google.com/group/proje...6f45e62616fa1e

J'ai eu une grosse réponse que je dois éplucher. (Et une morale de 12 aussi)

[g_rare]

Ce n'est pas de la pollution. Traiter le code normal de Java de polluant, c'est forcer l'esprit des développeurs à chercher des alternatives à tout prix alors que Java n'est pas conçu pour être moins verbeux.

+1!
Je rajouterais même qu'il ne faut pas confondre "verbosité" et "lisibilité" du code : un code verbeux est par définition auto-expressif (pas besoin de maîtriser de complexes mécanismes sous-jacents), donc un code verbeux est selon moi souvent bien plus lisible qu'un code court mais peu auto-expressif.

Je suis résolument contre le détournement des annotations dans ce contexte. Les annotations permettent l'ajout de fonctionnalités, à côté du code, pas du code tout court. Selon moi, ce genre de framework n'est pas pour les bons programmeurs paresseux, mais pour les mauvais programmeurs paresseux car ils oublient qu'ils programment en Java et pas dans un autre langage. Si d'autres langages supportent les properties nativement, qu'ils les utilisent. Pour l'instant, Java ne le fait pas et en faire une mauvaise émulation est pire qu'attendre la solution native.

+1!
Rien à rajouter à ce très bon rappel

[_skip]

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.

[pomauguet]

Pourquoi rajouter un framework pour ne pas se taper les getter et les setter... ça me dépasse. Comme dit par certains prédecesseurs, des annotations ne doivent pas être du code, et Eclipse (ou tout autre IDE un peu évolué) permet de macro-tiser ces choses un peu répétitives. Mais franchement, la difficulté du codage n'est pas dans les get et les set (ni dans les throws exception).

Je me demande si parfois les possibilités incroyables de Java par l'introspection, les annotations, ne sont pas dévoyées pour ne servir qu'à de la branlette intellectuelle.

La profusion de framework va finir par tuer le Java, moi c'est ça que je crains.

J'ai l'impression que certains sont attirés par les frameworks Java comme on peut l'être pour les application pour un iPhone. Oh regarde la nouvelle application que j'ai installé, elle ne fait rien, elle coûte cher, mais elle est trop fun...

[dingoth]

Oh, tu sais, quel que soit le langage, nombre de personnes ont créé des frameworks, des librairies. On a déjà vu ça, on reverra ça dans 10 ans, quand une autre technologie aura remplacé Java.

En ce qui concerne Java, c'est d'autant plus visible que pour une fois, il y a une technologie qui a un ascendant certain (en termes d'utilisateurs), et que nous sommes dans l'ère web.

Ben je plussoie mon compatriote ci-dessus.

Sommes nous vraiment compatriotes ? J'ai la nette impression que Bruxelles ne se trouve pas vraiment en Suisse

[_skip]

C'est parce que j'ai commencé le post avant de voir ta réponse...

Je suis entièrement contre la surenchère de framework (surtout venant du monde C++ et C#), toutefois j'aime pas taper des trucs suffisamment cons pour être générés par des compilateurs.

La solution optimale est clairement le support langage, comme en C# mais puisque nous l'avons pas, je m'intéresse aux solutions.

[dingoth]

Je comprends le besoin également. Combien de fois n'ai-je pesté contre la suppression des properties dans le JDK 7 !

Cependant, je préfère rester dans les monde "ce que la source dit, le code le fait", et je tente de m'y maintenir (donc, l'AOP... très peu pour moi), même avec la foule d'annotations auxquelles j'ai affaire.

[_skip]

Concernant lombok et la documentation, une proposition a été acceptés pour inclure une syntaxe permettant à delombok de recréer des commentaires javadoc.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
 
/**
* Ce commentaire sera inclu à la fois sur le getter et le setter (acceptation null, référence à des constantes etc...)
* <getter>ce texte facultatif est spécifique au getter</getter>
* <setter>ce texte facultatif est spécifique au setter</setter>
* @param documentation de set @param facultative
* @return documentation de get @return facultative
*/
@Getter @Setter
private String propriete

Vous pourriez donc par exemple écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
/**
* @param The new value for property, null = auto-detect 
* @return The current value of property, can be null 
*/
@Getter @Setter
private String property

Perso ça me semble pas mal et ça évite la duplication.