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

Le , 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 :

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?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 10/02/2010 à 12:51
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 .
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 10/02/2010 à 13:04
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++
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 10/02/2010 à 13:12
A travers mon post je ne voulais pas te contredire en fait...
Avatar de thebloodyman thebloodyman - Membre confirmé https://www.developpez.com
le 10/02/2010 à 18:42
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
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 08/03/2010 à 9:05
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.
Avatar de clincks clincks - Nouveau membre du Club https://www.developpez.com
le 05/07/2010 à 20:05
Citation Envoyé par _skip  Voir le message
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.
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 05/07/2010 à 20:37
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é.
Avatar de fmarot fmarot - Nouveau membre du Club https://www.developpez.com
le 05/07/2010 à 21:03
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.
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 19/10/2010 à 9:26
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à.
Avatar de clincks clincks - Nouveau membre du Club https://www.developpez.com
le 26/12/2010 à 15:26
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.
Avatar de thierryler thierryler - Rédacteur https://www.developpez.com
le 18/08/2014 à 21:42
Quelques compléments dans cet articles sur dvp : http://thierry-leriche-dessirier.dev...-guava-lombok/
Offres d'emploi IT
Ingénieur analyste programmeur (H/F)
Safran - Auvergne - Montluçon (03100)
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Data scientist senior H/F
Safran - Ile de France - Magny-les-Hameaux (Saclay)

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Java : Mickael Baron - Robin56 -