Est-il sûr d'utiliser Project Lombok? [fermé]

436

Dans le cas où vous ne savez pas que Project Lombok aide avec certains des ennuis de Java avec des choses comme la génération de getters et de setters avec des annotations et même une simple génération de JavaBean comme avec @Data . Cela pourrait vraiment m'aider, en particulier dans 50 objets d'événement différents où vous avez jusqu'à 7 champs différents qui doivent être construits et cachés avec des getters. Je pourrais supprimer près d'un millier de lignes de code avec cela.

Cependant, je crains qu'à long terme, ce ne soit une décision regrettable. Flamewars éclatera dans le ##Java Freenodecanal lorsque je le mentionnerai, fournir des extraits de code confondra les assistants possibles, les gens se plaindront de l'absence de JavaDoc , et les futurs valideurs pourraient tout simplement le supprimer de toute façon. J'apprécierais vraiment le positif, mais je m'inquiète du négatif.

Donc: est-il sûr d'utiliser Lombok sur n'importe quel projet, petit ou grand? Les effets positifs valent-ils les négatifs?

TheLQ
la source
5
Ajouter le support du compilateur jdk9 # 985 n'est pas résolu au moment de mon commentaire. Le système de package de Java 9 nécessite l'ajout de nombreuses options CLI javacafin d'ouvrir l'accès aux sun.*classes internes ((
gavenkoa
1
Peut-être intéressant: medium.com/@gabor.liptak/…
Gábor Lipták
De nos jours, les projets utilisent le préprocesseur d'annotation intégré à javac pour faire des choses comme ça - ce mécanisme est standard et on peut s'attendre à ce que les bons programmeurs le sachent.
Thorbjørn Ravn Andersen

Réponses:

182

Il semble que vous ayez déjà décidé que le projet Lombok vous offre des avantages techniques importants pour votre nouveau projet proposé. (Pour être clair dès le départ, je n'ai pas d'opinion particulière sur le projet Lombok, dans un sens ou dans l'autre.)

Avant d'utiliser Project Lombok (ou toute autre technologie révolutionnaire) dans un projet (open source ou autre), vous devez vous assurer que les parties prenantes du projet y consentent. Cela inclut les développeurs et tous les utilisateurs importants (par exemple, les sponsors formels ou informels).

Vous mentionnez ces problèmes potentiels:

Flamewars éclatera dans le canal ## Java Freenode quand je le mentionnerai,

Facile. Ignorez / ne participez pas aux guerres de flammes, ou abstenez-vous simplement de mentionner Lombok.

fournir des extraits de code confondra les assistants potentiels,

Si la stratégie du projet consiste à utiliser Lombok, les éventuels assistants devront s'y habituer.

les gens se plaindront de manquer JavaDoc,

Voilà leur problème. Personne sensé n'essaie d'appliquer de manière rigide les règles de code source / documentation de leur organisation à des logiciels open source tiers. L'équipe de projet doit être libre de définir le code source du projet / les normes de documentation qui conviennent à la technologie utilisée.

( SUIVI - Les développeurs de Lombok reconnaissent que la non-génération de commentaires javadoc pour les méthodes getter et setter synthétisées est un problème. S'il s'agit d'un problème majeur pour vos projets, alors une alternative est de créer et de soumettre un patch Lombok pour résoudre ce problème. )

et les futurs valideurs pourraient tout simplement le supprimer de toute façon.

Ce n'est pas allumé! Si la stratégie de projet convenue consiste à utiliser Lombok, les auteurs qui dé-Lombokent le code doivent être châtiés et, si nécessaire, leurs droits d'engagement doivent être retirés.

Bien sûr, cela suppose que vous avez l'adhésion des parties prenantes ... y compris des développeurs. Et cela suppose que vous êtes prêt à défendre votre cause et à gérer de manière appropriée les inévitables voix dissidentes.

Stephen C
la source
77
En tant que développeur Lombok, je peux dire que la génération de javadoc est techniquement possible. Veuillez participer au groupe Google si vous avez des idées brillantes sur la façon de le mettre en œuvre. Je veux dire, simplement générer un texte standard n'est pas très utile. Comme getFoo, renvoie foo, setFoo définit le foo? Comment cela va-t-il aider?
Roel Spilker
177
Je dirais que javadoc pour les accesseurs / décanteurs de haricots fait plus de mal que de bien. Ces méthodes suivent une convention bien comprise qui n'a pas besoin d'être ajoutée au javadoc; cela ne fait qu'ajouter au bruit. N'ajoutez de la documentation aux getters et setters que lorsqu'ils font quelque chose d'inattendu, c'est-à-dire lorsqu'ils ont des effets secondaires.
GaryF
9
Je viens de réaliser que la remarque javadoc pourrait faire référence au fait que si vous générez javadoc pour votre code lomboked, les getters et setters ne s'affichent pas du tout. La façon de résoudre ce problème consiste à exécuter javadoc sur votre code supprimé.
Roel Spilker
14
@GaryF Vraiment? Que diriez-vous de documenter si la valeur peut être nulle? Ou la plage autorisée pour une valeur numérique? Ou la longueur et / ou le format autorisés d'une valeur de chaîne? Ou si une valeur de chaîne convient à la présentation à un utilisateur final? Ou documenter ce que la propriété signifie réellement, quand son nom ne peut pas l'expliquer en entier? ( JList.getLayoutOrientation et JList.setLayoutOrientation me viennent à l'esprit.)
VGR
21
@VGR Je suis d'accord avec ce que vous dites en général, mais une meilleure solution dans ce cas spécifique est une meilleure dénomination, pas des commentaires. à- dire getCreationDate, getDueDate. La dénomination l'emporte sur les commentaires lorsque cela est possible.
GaryF
850

Je viens de commencer à utiliser Lombok aujourd'hui. Jusqu'à présent, je l'aime bien, mais un inconvénient que je n'ai pas vu mentionné était la refactorisation du support.

Si vous avez une classe annotée @Data, elle générera les getters et setters pour vous en fonction des noms de champs. Si vous utilisez l'un de ces getters dans une autre classe, puis décidez que le champ est mal nommé, il ne trouvera pas les utilisations de ces getters et setters et remplacera l'ancien nom par le nouveau nom.

J'imagine que cela devrait être fait via un plug-in IDE et non via Lombok.

MISE À JOUR (22 janvier 13)
Après avoir utilisé Lombok pendant 3 mois, je le recommande toujours pour la plupart des projets. J'ai cependant trouvé un autre inconvénient similaire à celui indiqué ci-dessus.

Si vous avez une classe, disons MyCompoundObject.javaqu'elle a 2 membres, tous les deux annotés avec @Delegate, disons myWidgetset myGadgets, lorsque vous appelez myCompoundObject.getThingies()d'une autre classe, il est impossible de savoir si elle délègue à Widgetou Gadgetparce que vous ne pouvez plus accéder à la source dans l'EDI.

L'utilisation d'Eclipse "Generate Delegate Methods ..." vous offre les mêmes fonctionnalités, est tout aussi rapide et fournit un saut de source. L'inconvénient est qu'il encombre votre source avec du code passe-partout qui détourne l'attention des choses importantes.

MISE À JOUR 2 (26 février 13)
Après 5 mois, nous utilisons toujours Lombok, mais j'ai d'autres ennuis. L'absence d'un getter & setter déclaré peut devenir ennuyeux lorsque vous essayez de vous familiariser avec le nouveau code.

Par exemple, si je vois une méthode appelée getDynamicCols()mais je ne sais pas de quoi il s'agit, j'ai quelques obstacles supplémentaires à franchir pour déterminer le but de cette méthode. Certains des obstacles sont Lombok, certains sont le manque d'un plugin intelligent Lombok. Les obstacles comprennent:

  • Manque de JavaDocs. Si je javadoce le champ, j'espère que le getter et le setter hériteront de ce javadoc via l'étape de compilation de Lombok.
  • Aller à la définition de méthode me renvoie à la classe, mais pas à la propriété qui a généré le getter. Il s'agit d'un problème de plugin.
  • De toute évidence, vous n'êtes pas en mesure de définir un point d'arrêt dans un getter / setter, sauf si vous générez ou codez la méthode.
  • REMARQUE: cette recherche de référence n'est pas un problème comme je l'avais pensé pour la première fois. Vous devez cependant utiliser une perspective qui active la vue Structure. Pas un problème pour la plupart des développeurs. Mon problème était que j'utilisais Mylyn qui filtrait ma Outlinevue, donc je n'ai pas vu les méthodes. Recherche de manque de références. Si je veux voir qui appelle getDynamicCols(args...), je dois générer ou coder le passeur pour pouvoir rechercher des références.

MISE À JOUR 3 (7 mars 2013)
Apprendre à utiliser les différentes façons de faire les choses dans Eclipse, je suppose. Vous pouvez réellement définir un point d'arrêt conditionnel (BP) sur une méthode générée par Lombok. À l'aide de la Outlinevue, vous pouvez cliquer avec le bouton droit sur la méthode pour Toggle Method Breakpoint. Ensuite, lorsque vous appuyez sur le BP, vous pouvez utiliser la Variablesvue de débogage pour voir comment la méthode générée a nommé les paramètres (généralement les mêmes que le nom du champ) et enfin, utiliser la Breakpointsvue pour cliquer avec le bouton droit sur le BP et sélectionner Breakpoint Properties...pour ajouter une condition. Agréable.

MISE À JOUR 4 (16 août 13)
Netbeans ne l'aime pas lorsque vous mettez à jour vos dépendances Lombok dans votre pom Maven. Le projet compile toujours, mais les fichiers sont marqués pour avoir des erreurs de compilation car il ne peut pas voir les méthodes que Lombok crée. L'effacement du cache Netbeans résout le problème. Je ne sais pas s'il existe une option "Clean Project" comme il y en a dans Eclipse. Problème mineur, mais je voulais le faire savoir.

MISE À JOUR 5 (17 janvier 14)
Lombok ne joue pas toujours bien avec Groovy, ou du moins avec groovy-eclipse-compiler. Vous devrez peut-être rétrograder votre version du compilateur. Maven Groovy et Java + Lombok

MISE À JOUR 6 (26 juin 14)
Un mot d'avertissement. Lombok est légèrement addictif et si vous travaillez sur un projet où vous ne pouvez pas l'utiliser pour une raison quelconque, cela vous ennuiera. Il vaut peut-être mieux ne jamais l'utiliser du tout.

MISE À JOUR 7 (23 juil. 14)
Il s'agit d'une mise à jour intéressante car elle traite directement de la sécurité de l'adoption de Lombok sur laquelle le PO a posé des questions.

Depuis la v1.14, l' @Delegateannotation a été rétrogradée à un statut expérimental. Les détails sont documentés sur leur site ( Lombok Delegate Docs ).

Le fait est que si vous utilisiez cette fonctionnalité, vos options de sauvegarde sont limitées. Je vois les options comme:

  • Supprimez manuellement les @Delegateannotations et générez / codez manuellement le code délégué. C'est un peu plus difficile si vous utilisiez des attributs dans l'annotation.
  • Delombok les fichiers qui ont l' @Delegateannotation et ajoutez peut-être dans les annotations que vous voulez.
  • Ne jamais mettre à jour Lombok ou maintenir une fourchette (ou vivre avec des fonctionnalités expérientielles).
  • Delombok l'ensemble de votre projet et arrêtez d'utiliser Lombok.

Autant que je sache , Delombok n'a pas d'option pour supprimer un sous-ensemble d'annotations ; c'est tout ou rien du moins pour le contexte d'un seul fichier. J'ai ouvert un ticket pour demander cette fonctionnalité avec des drapeaux Delombok, mais je ne m'attendrais pas à cela dans un avenir proche.

MISE À JOUR 8 (20 oct. 14)
Si c'est une option pour vous, Groovy offre la plupart des mêmes avantages de Lombok, ainsi qu'une multitude d'autres fonctionnalités, dont @Delegate . Si vous pensez que vous aurez du mal à vendre l'idée aux pouvoirs en place, jetez un œil à l' annotation @CompileStaticou @TypeCheckedpour voir si cela peut aider votre cause. En fait, l'objectif principal de la version Groovy 2.0 était la sécurité statique .

MISE À JOUR 9 (1er septembre 2015)
Lombok est toujours activement entretenu et amélioré , ce qui augure bien du niveau de sécurité de l'adoption. Les annotations @Builder sont l'une de mes nouvelles fonctionnalités préférées.

MISE À JOUR 10 (17 nov. 15)
Cela peut ne pas sembler directement lié à la question du PO, mais mérite d'être partagé. Si vous recherchez des outils pour vous aider à réduire la quantité de code passe-partout que vous écrivez, vous pouvez également consulter Google Auto - en particulier AutoValue . Si vous regardez leur diaporama , la liste Lombok comme une solution possible au problème qu'ils essaient de résoudre. Les inconvénients qu'ils énumèrent pour Lombok sont:

  • Le code inséré est invisible (vous ne pouvez pas "voir" les méthodes qu'il génère) [ed note - en fait vous pouvez, mais il nécessite juste un décompilateur]
  • Les hacks du compilateur sont non standard et fragiles
  • "Selon nous, votre code n'est plus vraiment Java"

Je ne sais pas dans quelle mesure je suis d'accord avec leur évaluation. Et compte tenu des inconvénients d'AutoValue qui sont documentés dans les diapositives, je resterai avec Lombok (si Groovy n'est pas une option).

MISE À JOUR 11 (8 février 16)
J'ai découvert que Spring Roo a des annotations similaires . J'ai été un peu surpris de découvrir que Roo est toujours une chose et trouver de la documentation pour les annotations est un peu difficile. L'enlèvement ne semble pas aussi facile que de-lombok. Lombok semble être le choix le plus sûr.

MISE À JOUR 12 (17 février 16)
En essayant de trouver des raisons pour lesquelles il est sûr de faire appel à Lombok pour le projet sur lequel je travaille actuellement, j'ai trouvé une pièce d'or qui a été ajoutée avec v1.14- Le système de configuration ! Cela signifie que vous pouvez configurer un projet pour interdire certaines fonctionnalités que votre équipe juge dangereuses ou indésirables. Mieux encore, il peut également créer une configuration spécifique au répertoire avec différents paramètres. C'est génial.

MISE À JOUR 13 (4 octobre 16)
Si ce genre de chose vous importe, Oliver Gierke a estimé qu'il était sûr d' ajouter Lombok à Spring Data Rest .

MISE À JOUR 14 (26 sept. 17)
Comme l'a souligné @gavenkoa dans les commentaires sur la question OP, le support du compilateur JDK9 n'est pas encore disponible (problème # 985). Il semble également que cela ne sera pas une solution facile pour l'équipe de Lombok de se déplacer.

MISE À JOUR 15 (26 mars 18)
Le journal des modifications de Lombok indique à partir de v1.16.20 "La compilation de lombok sur JDK1.9 est maintenant possible " même si # 985 est toujours ouvert.

Cependant, les changements pour prendre en charge JDK9 ont nécessité des changements de rupture; tous isolés des modifications des paramètres de configuration par défaut. Il est un peu inquiétant qu'ils aient introduit des changements de rupture, mais la version n'a fait que doubler le numéro de version "incrémentiel" (passant de v1.16.18 à v1.16.20). Étant donné que ce message concernait la sécurité, si vous aviez un yarn/npmsystème de construction similaire qui était automatiquement mis à niveau vers la dernière version incrémentielle, vous pourriez être dans un réveil brutal.

MISE À JOUR 16 (9 janvier 19)

Il semble que les problèmes JDK9 ont été résolus et Lombok fonctionne avec JDK10, et même JDK11 pour autant que je sache.

Une chose que j'ai remarquée, mais qui était préoccupante du point de vue de la sécurité, est le fait que le journal des modifications passant de la v1.18.2 à la v1.18.4 répertorie deux éléments comme BREAKING CHANGE!? Je ne sais pas comment un changement de rupture se produit dans une mise à jour semver "patch". Cela pourrait être un problème si vous utilisez un outil qui met à jour automatiquement les versions des correctifs.

Snekse
la source
49
Merci, je pense que ce sont les informations que le PO voulait vraiment, par opposition à une réponse philosophique.
chaostheory
14
UPDATE 6ressemble beaucoup à Scala :)
mauhiz
5
@mauhiz et Groovy. Si jamais je devais travailler dans un endroit où je ne pouvais pas utiliser Groovy ou Scala au moins pour les tests, j'arrêterais probablement en peu de temps.
Snekse
8
J'aime vraiment vos mises à jour au fil du temps. En particulier pour une question / réponse de ce style, cela aide vraiment.
MattG
4
Il semble que la prise en charge de Java 9 soit désormais disponible. Vous pouvez mettre à jour votre réponse. stackoverflow.com/questions/41520511/…
leventunver
115

Allez-y et utilisez Lombok, vous pouvez si nécessaire "delombok" votre code après http://projectlombok.org/features/delombok.html

Kennet
la source
5
@fastcodejava lorsque vous dites "+1 pour x", x devrait être l'un des points répertoriés et non le seul et unique point :)
Kerem Baydoğan
7
Dans cette situation particulière, j'ai interprété "+1 pour delombok" comme "long delombok". Je l'aime.
Zoltán
1
"+1 pour delombok" - particulièrement vrai lorsque vous souhaitez utiliser lombok dans des projets qui seront fournis à vos clients. Vous pouvez profiter de tous les avantages de lombok et laisser vos clients voir un pot propre sans dépendance lombok.
fwonce
Pour les gens qui pensent "ok, je vais essayer Lombok, et si je ne l'aime pas, je vais juste Delombok": réfléchissez bien L'exécution de Delombok est un processus douloureux. Et le code résultant fonctionnera comme il l'a fait avec Lombok ... mais ce sera aussi un gâchis complet.
AJPerez
75

Personnellement (et donc subjectivement), j'ai trouvé que l'utilisation de Lombok rend mon code plus expressif sur ce que j'essaie de réaliser par rapport à l'IDE / propre implémentation de méthodes complexes telles que hashcode & equals.

Lors de l'utilisation

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

il est beaucoup plus facile de garder Equals & HashCode cohérent et de garder une trace des champs évalués, que n'importe quelle implémentation IDE / propre. Cela est particulièrement vrai lorsque vous ajoutez / supprimez régulièrement des champs.

Il en va de même pour l' @ToStringannotation et ses paramètres qui communiquent clairement le comportement souhaité en ce qui concerne les champs inclus / exclus, l'utilisation des getters ou l'accès aux champs et s'il faut ou non appeler super.toString().

Et encore une fois en annotant une classe entière avec @Getterou @Setter(AccessLevel.NONE)(et éventuellement en remplaçant les méthodes divergentes), il est immédiatement clair quelles méthodes seront disponibles pour les champs.

Les avantages continuent indéfiniment ..

Dans mon esprit, il ne s'agit pas de réduire le code, mais de communiquer clairement ce que vous souhaitez réaliser, plutôt que d'avoir à le comprendre à partir de Javadoc ou d'implémentations. Le code réduit facilite simplement la détection des implémentations de méthodes divergentes.

Tim
la source
21
Et pour ajouter à cela: le passage à Lombok a en fait permis de résoudre certains bogues complexes dans le passé en raison d'implémentations égales / hashCode incompatibles, et des cas dans lesquels j'ai oublié de mettre à jour les méthodes maintenant générées lorsqu'un champ a été ajouté. Ces avantages potentiels devraient être en mesure d'équilibrer la plupart des points négatifs que vous avez mentionnés.
Tim
25

Lombok est génial, mais ...

Lombok enfreint les règles du traitement des annotations, car il ne génère pas de nouveaux fichiers source. Cela signifie qu'il ne peut pas être utilisé avec d'autres processeurs d'annotation s'ils s'attendent à ce que les getters / setters ou quoi que ce soit d'autre existent.

Le traitement des annotations s'exécute en une série de tours. À chaque tour, chacun a son tour de courir. Si de nouveaux fichiers java sont trouvés après la fin du tour, un autre tour commence. De cette façon, l'ordre des processeurs d'annotation n'a pas d'importance s'ils ne génèrent que de nouveaux fichiers. Étant donné que lombok ne génère aucun nouveau fichier, aucun nouveau cycle n'est démarré, donc certains AP qui s'appuient sur le code lombok ne s'exécutent pas comme prévu. Cela a été une énorme source de douleur pour moi lors de l'utilisation de mapstruct, et le délombokage n'est pas une option utile car il détruit vos numéros de ligne dans les journaux.

J'ai finalement piraté un script de construction pour travailler avec lombok et mapstruct. Mais je veux laisser tomber lombok en raison de la façon dont il est hacky - au moins dans ce projet. J'utilise lombok tout le temps dans d'autres trucs.

twentylemon
la source
22

J'ai lu quelques opinions sur le Lombok et en fait je l'utilise dans certains projets.

Eh bien, lors du premier contact avec Lombok, j'ai eu une mauvaise impression. Après quelques semaines, j'ai commencé à l'aimer. Mais après quelques mois, je trouve de nombreux petits problèmes à l'utiliser. Donc, ma dernière impression sur Lombok n'est pas si positive.

Mes raisons de penser de cette façon:

  • Dépendance du plugin IDE . Le support IDE pour Lombok se fait via des plugins. Même en fonctionnant bien dans la plupart du temps, vous êtes toujours un otage de ces plugins à maintenir dans les futures versions des IDE et même dans la version du langage (Java 10+ accélérera le développement du langage). Par exemple, j'ai essayé de mettre à jour Intellij IDEA 2017.3 vers 2018.1 et je n'ai pas pu le faire car il y avait un problème sur la version actuelle du plugin lombok et j'ai dû attendre que le plugin soit mis à jour ... C'est aussi un problème si vous aimerait utiliser un IDE plus alternatif qui ne prend pas en charge le plugin Lombok.
  • Problème de «recherche d'usages». . En utilisant Lombok, vous ne voyez pas les méthodes getter, setter, constructeur, constructeur générées, etc. Donc, si vous prévoyez de savoir où ces méthodes sont utilisées dans votre projet par votre IDE, vous ne pouvez pas le faire uniquement en regardant pour la classe qui possède ces méthodes cachées.
  • Si facile que les développeurs ne se soucient pas de briser l'encapsulation . Je sais que ce n'est pas vraiment un problème de Lombok. Mais j'ai vu une plus grande tendance de la part des développeurs à ne plus contrôler quelles méthodes doivent être visibles ou non. Ainsi, plusieurs fois, ils ne font que copier et coller des @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorannotations sans penser aux méthodes que la classe doit vraiment exposer.
  • Builder Obssession ©. J'ai inventé ce nom (descendez, Martin Fowler). À part les blagues, un générateur est si facile à créer que même lorsqu'une classe n'a que deux paramètres, les développeurs préfèrent utiliser @Builderau lieu de constructeur ou d'une méthode de constructeur statique. Parfois, ils essaient même de créer un Builder à l'intérieur du lombok Builder, créant des situations étranges comme MyClass.builder().name("Name").build().create().
  • Obstacles lors de la refactorisation . Si vous utilisez, par exemple, a @AllArgsConstructoret devez ajouter un paramètre supplémentaire sur le constructeur, l'EDI ne peut pas vous aider à ajouter ce paramètre supplémentaire à tous les endroits (principalement des tests) qui instancient la classe.
  • Mélanger Lombok avec des méthodes concrètes . Vous ne pouvez pas utiliser Lombok dans tous les scénarios pour créer un getter / setter / etc. Ainsi, vous verrez ces deux approches mélangées dans votre code. Vous vous habituez à cela après un certain temps, mais vous vous sentez comme un hack sur la langue.

Comme une autre réponse l'a dit, si vous êtes en colère contre la verbosité Java et utilisez Lombok pour y faire face, essayez Kotlin.

Dherik
la source
8
Je dirais opter pour Kotlin ou rester avec Java simple. Vous pouvez passer plus de temps à contourner les problèmes de Lombok que vous n'en économisez en ne tapant pas le code java.
jediz
1
Quiconque déteste Java uniquement à cause de la verbosité est de sa faute pour ne pas avoir rendu son code moins verbeux ...
Nikolas
17

Il existe également des risques de maintenance à long terme. Tout d'abord, je vous recommande de lire comment Lombok fonctionne réellement, par exemple quelques réponses de ses développeurs ici .

Le site officiel contient également une liste des inconvénients , y compris cette citation de Reinier Zwitserloot:

C'est un hack total. Utilisation d'une API non publique. Casting présomptueux (sachant qu'un processeur d'annotation fonctionnant dans javac obtiendra une instance de JavacAnnotationProcessor, qui est l'implémentation interne d'AnnotationProcessor (une interface), qui se trouve donc avoir quelques méthodes supplémentaires qui sont utilisées pour obtenir l'AST en direct) .

Sur eclipse, c'est sans doute pire (et pourtant plus robuste) - un agent java est utilisé pour injecter du code dans la classe de grammaire et d'analyseur eclipse, qui est bien sûr une API entièrement non publique et totalement hors limites.

Si vous pouviez faire ce que lombok fait avec l'API standard, je l'aurais fait de cette façon, mais vous ne pouvez pas. Pourtant, pour ce que cela vaut, j'ai développé le plugin eclipse pour eclipse v3.5 fonctionnant sur java 1.6, et sans apporter de modifications, il a également fonctionné sur eclipse v3.4 fonctionnant sur java 1.5, il n'est donc pas complètement fragile.

En résumé, bien que Lombok puisse vous faire gagner du temps de développement, s'il existe une mise à jour javac non rétrocompatible (par exemple une atténuation de vulnérabilité), Lombok pourrait vous coincer avec une ancienne version de Java pendant que les développeurs s'efforcent de mettre à jour leur utilisation de ceux-ci. API internes. Que ce soit un risque sérieux dépend évidemment du projet.

dskrvk
la source
8
Eh bien, si vous ne pouvez plus utiliser Lombok, lancez simplement delombok et continuez le développement sans lui.
vladich
3
C'est comme apprendre à conduire avec des lunettes puis à les perdre avant le test de conduite. Si votre équipe est habituée à travailler avec du code Lombok'ed et est soudainement obligée de changer son processus en raison d'un changement de rupture, cela aura un impact énorme sur les projets en cours. N'est-il pas préférable d'éviter complètement ce risque et d'utiliser un cadre qui ne repose pas sur des fonctionnalités non documentées ou un langage comme Scala qui fournit les mêmes fonctionnalités dès le départ?
dskrvk
15

Je sais que je suis en retard, mais je ne résiste pas à la tentation: quiconque aime Lombok devrait également jeter un coup d'œil à Scala. Beaucoup de bonnes idées que vous trouvez à Lombok font partie de la langue Scala.

Sur votre question: il est certainement plus facile de faire essayer Lombok à vos développeurs que Scala. Essayez-le et s'ils l'aiment, essayez Scala.

Juste un avertissement: j'aime aussi Java!

Sorencito
la source
J'aime Scala et Lombok, mais je ne vois pas de quelles idées vous parlez. \ @SneakyThrows, \ @Data, ...?
sinuhepop
2
@sinuhepop La génération de getters et setters ressemble à des classes de cas. La fonctionnalité immuable est inhérente à Scala et les API enrichissantes concernant vos propres méthodes sont également une fonctionnalité intégrée de Scala.
sorencito
5
essayez aussi Kotlin
jediz
15

J'ai utilisé Lombok dans presque tous mes projets pendant un an mais je l'ai malheureusement supprimé. Au début, c'était un moyen de développement très propre, mais la mise en place de l'environnement de développement pour les nouveaux membres de l'équipe n'est pas très facile et directe. Quand c'est devenu un mal de tête, je l'ai juste retiré. Mais c'est un bon travail et a besoin de plus de simplicité de mise en place.

vici
la source
27
pouvez-vous expliquer les maux de tête?
Kevin Welker
2
La configuration d'Eclipse est extrêmement simple. Juste "java -jar lombok.jar".
14
Je pense que la partie la plus difficile de la mise en place d'un nouveau développeur est de réaliser que vous devez configurer Lombok. Il n'y a aucun message disant "Lombok n'a pas été configuré" ou quelque chose comme ça. Au lieu de cela, vous obtenez des messages étranges comme "setFoo" n'est pas défini. Si l'éducation à Lombok ne fait pas partie de votre nouveau processus de formation à bord pour les développeurs, il y aura une grande confusion.
Snekse
@Snekse. Je ne sais pas exactement quelle version du plugin lombok a introduit la notification et la suggestion d'intellij (un message et une suggestion rouges apparaissent dans le journal des erreurs pour inviter l'utilisateur à activer l'annotation et même fourni le lien vers la section de configuration), mais Idea 2016.3 et la version du plugin 0.13.16 contient contient ce support utile.
jtonic
2
Le plugin lombok idea (j'utilise la version 0.13.16) introduit récemment le support pour informer l'utilisateur que le processeur d'annotation n'a pas été configuré et fournit également un lien vers la section des paramètres de configuration pour activer l'apt. Veuillez voir la capture d'écran sur. postimg.org/image/5tm2zzvkh
jtonic
11

Quand j'ai montré le projet à mon équipe, l'enthousiasme était élevé, donc je pense que vous ne devriez pas avoir peur de la réponse de l'équipe.

  • En ce qui concerne le retour sur investissement, c'est un composant logiciel enfichable à intégrer, et ne nécessite aucun changement de code dans sa forme de base. (il suffit d'ajouter une seule annotation à votre classe)

  • Et enfin, si vous changez d'avis, vous pouvez exécuter le unlombok, ou laisser votre IDE créer ces setters, getters et ctors, (ce que je pense que personne ne demandera une fois qu'ils verront à quel point votre pojo devient clair)

Dov Tsal S
la source
10

Mon point de vue sur Lombok est qu'il fournit simplement des raccourcis pour écrire du code Java bolilerplate.
Quand il s'agit d'utiliser des raccourcis pour écrire du code Java de bolilerplate, je me baserais sur les fonctionnalités fournies par IDE - comme dans Eclipse, nous pouvons aller dans le menu Source> Générer des getters et des setters pour générer des getters et setters.
Je ne compterais pas sur une bibliothèque comme Lombok pour ça:

  1. Il pollue votre code avec une couche d'indirection de syntaxe alternative (lecture @Getter, @Setteretc. annotations). Plutôt que d'apprendre une syntaxe alternative pour Java, je passerais à n'importe quel autre langage qui fournit nativement une syntaxe semblable à Lombok.
  2. Lombok nécessite l'utilisation d'un IDE pris en charge par Lombok pour fonctionner avec votre code. Cette dépendance introduit un risque considérable pour tout projet non trivial. Le projet open source Lombok a-t-il suffisamment de ressources pour continuer à fournir un support pour différentes versions d'une large gamme d'IDE Java disponibles?
  3. Le projet open source Lombok dispose-t-il de suffisamment de ressources pour continuer à prendre en charge les nouvelles versions de Java qui arriveront à l'avenir?
  4. Je suis également nerveux que Lombok puisse introduire des problèmes de compatibilité avec les frameworks / bibliothèques largement utilisés (comme Spring, Hibernate, Jackson, JUnit, Mockito) qui fonctionnent avec votre code d'octet au moment de l'exécution.

Dans l'ensemble, je ne préférerais pas "pimenter" mon Java avec Lombok.

Sanjeev Sachdev
la source
Un contre-argument à cela serait - et si quelqu'un utilisait IDE pour construire toute la plaque de construction d'un POJO, mais plus tard l'un des getters / setters a été renommé ou supprimé. La classe n'est plus un POJO strict, mais cela doit être déduit d'une inspection minutieuse de toutes les méthodes de la classe. Je trouve que les annotations lombok évitent au moins cela et rendent la logique commerciale de mes classes beaucoup plus saillante. Tous vos points sont valables; cependant, je voulais juste offrir cette pensée. Et lombok va plus loin avec @ Data / @ Value / @ Utility / @ Builder
Adam Hughes
10

Voulait utiliser lombok @ToStringmais a rapidement fait face à des erreurs de compilation aléatoires lors de la reconstruction du projet dans Intellij IDEA. J'ai dû frapper la compilation plusieurs fois avant que la compilation incrémentielle puisse se terminer avec succès.

J'ai essayé à la fois lombok 1.12.2 et 0.9.3 avec Intellij IDEA 12.1.6 et 13.0 sans aucun plugin lombok sous jdk 1.6.0_39 et 1.6.0_45.

J'ai dû copier manuellement les méthodes générées à partir de la source delomboked et mettre lombok en attente jusqu'à des moments meilleurs.

Mise à jour

Le problème se produit uniquement avec la compilation parallèle activée.

Dépôt d'un problème: https://github.com/rzwitserloot/lombok/issues/648

Mise à jour

mplushnikov a commenté le 30 janvier 2016:

La nouvelle version d'Intellij n'a plus de tels problèmes. Je pense qu'il peut être fermé ici.

Mise à jour

Je recommanderais fortement de passer de Java + Lombok à Kotlin si possible. Comme il a résolu de fond en comble tous les problèmes Java que Lombok essaie de contourner.

Vadzim
la source
6

J'ai rencontré un problème avec Lombok et Jackson CSV , lorsque j'ai marshalisé mon objet (jean bean) dans un fichier CSV, où les colonnes ont été dupliquées, puis j'ai supprimé l'annotation @Data de Lombok et la marshalisation a bien fonctionné.

Gugelhupf
la source
2

Je ne le recommande pas. J'avais l'habitude de l'utiliser, mais ensuite, lorsque je travaillais avec NetBeans 7.4, cela dérangeait mes codes. Je dois supprimer lombok dans tous les fichiers de mes projets. Il y a du delombok, mais comment puis-je être sûr qu'il ne visserait pas mes codes. Je dois passer des jours juste pour supprimer lombok et revenir aux styles Java ordinaires. J'ai juste trop épicé ...

Harun
la source
Alors, que recommandez-vous pour annoter JavaBeans?
IgorGanapolsky
L'équipe lombok a mis à jour son code. Pourtant, je dois attendre plusieurs mois avant qu'il ne soit prêt
Harun
0

Je n'ai pas encore essayé d'utiliser Lombok - c'est / était le prochain sur ma liste, mais il semble que Java 8 lui ait causé des problèmes importants, et des travaux de correction étaient toujours en cours il y a une semaine. Ma source pour cela est https://code.google.com/p/projectlombok/issues/detail?id=451 .

ChrisA
la source
Juste pour mémoire, ce problème a été migré vers github.com/rzwitserloot/lombok/issues/524
seanf
1
Je n'ai aucun problème avec lombok sur Java 8
Alexey
Je travaille avec lombok depuis des mois maintenant et cela fonctionne bien avec Java 8. Le projet sur lequel je travaille utilise déjà lombok depuis des années et aucun problème n'a été rencontré jusqu'à présent.
kevenlolo