Discussion :

[dingoth]

Toute considérations précédentes mises à part, cette syntaxe me dérange sur le fait que @param et @return sont utilisés. Pourquoi ? Parce que @param est "réservé" aux paramètres de méthodes, et qu'ici, dans le code, nous n'avons pas de paramètres. Il en sera généré un, certes, mais il n'y en a pas tel quel. Et pour marquer le fait que l'on est dans le contexte Lombok, il faudrait, selon moi, utiliser d'autres mots-clé, comme par exemple: @setter-param et @getter-return.

[_skip]

J'ai mis cette remarque sur le tracker, en effet surtout qu'en plus l'IDE risque de se mettre à râler.

[fmarot]

Merci Skip pour tes infos sur les futures évolutions permettant de documenter le code "lomboké". La direction prise me semble intéressante, modulo la remarque de Dingoth. A voir si ca pose vraiment probleme...
Sinon, je viens de penser à un truc là. J'aime bien le concept de lombok, mais avec le probleme de la doc par exemple on se rend compte que parfois on complique d'autre choses à force de vouloir en simplifier certaines. Finalement, le probleme est toute la pollution visuelle générée par des palanqués de getter/setter dont la présence à l'écran nous embete plus qu'autre chose. Si on se contentait de modifier les éditeurs de code (Eclipse) pour qu'ils n'affichent pas, par defaut, toutes ces méthodes ? Par contre, reste le probleme de la maintenance des commentaires lors d'un renommage de variable par exemple...

[_skip]

Disons qu'à mon sens, cette facilité d'écriture des Getter/Setter à elle-seule ne sert à rien sans une gestion de la documentation.
Je n'ai jamais eu l'intention d'utiliser Lombok sans cette possibilité, ce qui me brûle la peau des fesses dans les getters/setters c'est pas vraiment de devoir les écrire mais de devoir commenter les choses 3 fois, dans 3 formats différents.

S'il s'agit rien que de ne pas les voir, actuellement j'utilise une région que je peux collapser.

[thebloodyman]

Je pense que pour certains besoins récurrents, ca serait bien plus simple et standard si le langage Java évolué.

Personnellement, ca me dérange de dépendre d'une librairie tierce pour répondre à des besoins aussi standards qu'une gestion simplifiée des accesseurs/modificateurs.
Comme le précise dingoth, Java 7 avait initialement prévu la notion de propriété pour gérer ce besoin et c'est hélas tombé à l'eau.
C'est triste

[adiGuba]

Java 7 avait initialement prévu la notion de propriété pour gérer ce besoin et c'est hélas tombé à l'eau.

Cela n'a jamais été prévu.

Ca a été étudié dans le cas du projet Coin comme tant d'autres propositions d'évolutions du langage. Cela n'a pas été retenu pour diverses raisons, en particulier car aucune proposition n'a réussi à faire le consensus...

a+

[_skip]

Ca a été considéré, et même largement discuté au sein de la team java7 si j'en crois les blogs que j'ai eu l'occasion de lire.
La syntaxe proposée (->) était nulle, puis sûrement pas le temps et pas le fric chez Sun. Enfin, plus qu'à attendre le prochain cycle d'évolution, dans 6-10 ans.

Enfin que serait java sans tout ce "useless typing" après tout .

[adiGuba]

Ce que je veux dire c'est que ce n'a pas été prévu puis abondonné, mais simplement discuté. Car le projet Coin contenait plein de propositions qui partaient dans tous les sens. On ne peut pas dire pour autant que c'était prévu

En même temps vu l'absence de JSRs la visibilité de tout cela n'est pas très clair...

a++

[_skip]

A travers mon post je ne voulais pas te contredire en fait...

[thebloodyman]

Exact adiGuba.
J'aurais plutôt dire envisagé puisqu' étudié.
J'y croyais tellement à l'époque, c'est peut être pour ca

La syntaxe proposée (->) était nulle, puis sûrement pas le temps et pas le fric chez Sun

Pour le fric, tu penses vraiment que c'est le vrai problème ?
Il y a une communauté forte, bcp de dev compétents qui développent pour la communauté. Pourquoi ne pas les utiliser ?

Bon j'arrête de polluer ce sujet

[_skip]

Bon alors voici mon retour :

J'ai testé sur une application non critique, aucun souci de prise en charge avec netbeans si ce n'est un ou deux warning de l'IDE concernant les variables privées annotées Getter/Setter. L'autocomplétion fonctionne parfaitement, l'IDE détecte bien les méthodes générées puisqu'il compile les classes et utilise la réflexion par dessus.

Au niveau écriture, c'est très confortable dans le sens où il est à présent beaucoup moins lourd d'écrire des classes POJO typiques (objets correspondant à des enregistrements de base de données, classes de résultat d'une méthode ou d'un thread séparé). Bref, le code est beaucoup moins pollué, les méthodes intelligentes d'une classe ont une meilleure visibilité, celles-ci sont plus concises...

Reste le problème de la javadoc à ce jour, mais sinon je suis plutôt satisfait. Ca me conforte totalement dans mon opinion que les propriétés sont un must en java, si seulement on les avait en version 7 plutôt que tous ces gadgets (switch sur String, notation) qui me semblent n'être là que pour remplir une feuille de "new features" désespérément vide après toute cette attente.

En tout cas pour ceux qui veulent essayer lombok, vous pouvez y aller sans autres si vous êtes prêt à accepter ce *détournement* de l'usage des propriété. Détournement qui n'est pas franchement pire que ce que vous voyez dans les frameworks AOP.

[clincks]

Bon alors voici mon retour :

J'ai testé sur une application non critique, aucun souci de prise en charge avec netbeans si ce n'est un ou deux warning de l'IDE concernant les variables privées annotées Getter/Setter. L'autocomplétion fonctionne parfaitement, l'IDE détecte bien les méthodes générées puisqu'il compile les classes et utilise la réflexion par dessus.

Au niveau écriture, c'est très confortable dans le sens où il est à présent beaucoup moins lourd d'écrire des classes POJO typiques (objets correspondant à des enregistrements de base de données, classes de résultat d'une méthode ou d'un thread séparé). Bref, le code est beaucoup moins pollué, les méthodes intelligentes d'une classe ont une meilleure visibilité, celles-ci sont plus concises...

Reste le problème de la javadoc à ce jour, mais sinon je suis plutôt satisfait. Ca me conforte totalement dans mon opinion que les propriétés sont un must en java, si seulement on les avait en version 7 plutôt que tous ces gadgets (switch sur String, notation) qui me semblent n'être là que pour remplir une feuille de "new features" désespérément vide après toute cette attente.

En tout cas pour ceux qui veulent essayer lombok, vous pouvez y aller sans autres si vous êtes prêt à accepter ce *détournement* de l'usage des propriété. Détournement qui n'est pas franchement pire que ce que vous voyez dans les frameworks AOP.

Y a t'il une integration avec Maven?
Quid si on utilise un plugin maven dans Eclipse (m2 par exemple)?

Merci.

[_skip]

Tu peux l'utiliser avec Maven
http://projectlombok.org/mavenrepo/index.html

Pour eclipse, normalement oui mais je n'utilise pas eclipse et je n'ai donc pas essayé.

[fmarot]

Aucun probleme avec Maven et m2Eclipse, testé et grandement approuvé
meme si depuis j'ai laissé tombé m2eclipse (en version 0.9.8) pour mvn eclipse:eclipse.

[_skip]

Hello!

Juste une petite info pour indiquer que la 0.93 est sortie.
Au menu, des bugfixes et la génération de constructeurs.

http://projectlombok.org/features/Constructor.html

Malheureusement toujours pas de nouveautés en ce qui concerne la documentation des propriétés. Dommage car ça aurait été vraiment intéressant de pouvoir documenter un champ une fois et que sa doc soit reportée sur le constructeur, le getter et le setter...

Sinon, de mon côté j'ai utilisé lombok sur certains projets pour créer une masse de POJO servant de maps pour ibatis. Ca fonctionne plutôt bien pour ces classes qui n'ont justement pas vraiment de comportement métier, y'a pas à se plaindre de ce côté là.

[clincks]

Mes 2 cents pour lombok:

Imaginé le code à écrire pour hashcode() ou toString().

OK... c'est possible de le faire automatiquement avec eclipse ou autre IDE).

Mais... dans la vie d'un projet... qui n'a pas ajouté un membre à une classe?

--> Ce qui moi me plait particulièrement... c'est qu'il ne faut plus penser à regénerer le toString et le hashcode.

C'est souvent une source de bug... on est pressé... on oublie...

Donc... c'est mieux que du code généré par l'ide.

[thierryler]

Quelques compléments dans cet articles sur dvp : http://thierry-leriche-dessirier.dev...-guava-lombok/