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

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?

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.

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.

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

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.

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.

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.

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.

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!

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.

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)

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.

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.

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é.

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é ...

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 .