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.java
qu'elle a 2 membres, tous les deux annotés avec @Delegate
, disons myWidgets
et myGadgets
, lorsque vous appelez myCompoundObject.getThingies()
d'une autre classe, il est impossible de savoir si elle délègue à Widget
ou Gadget
parce 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
Outline
vue, 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 Outline
vue, 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 Variables
vue 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 Breakpoints
vue 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' @Delegate
annotation 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
@Delegate
annotations 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'
@Delegate
annotation 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 @CompileStatic
ou @TypeChecked
pour 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/npm
systè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.
javac
afin d'ouvrir l'accès auxsun.*
classes internes ((