Est-il prudent d'utiliser Project Lombok?
Si vous ne savez pas Projet Lombok aide à résoudre certains des inconvénients de Java avec des choses comme générer des getters et des setters avec des annotations et même - JavaBean simple comme génération 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 de mille lignes de code avec cela.
Cependant, je crains qu'à long terme, ce ne soit pas une décision regrettable. Des flamewars apparaîtront dans le canal ##Java Freenode lorsque je le mentionnerai, fournir des extraits de code déroutera d'éventuels assistants, les gens se plaindront de l'absence de JavaDoc , et les futurs responsables pourront tout simplement le supprimer. J'apprécierais vraiment le positif, mais le négatif m'inquiète.
Donc: est-il prudent d’utiliser Lombok dans n’importe quel projet, petit ou grand? Les effets positifs valent-ils les inconvénients?
Il semble que vous ayez déjà décidé que le projet Lombok vous confère d’importants avantages techniques pour le nouveau projet que vous proposez. (Pour être clair dès le début, je n’ai aucune opinion particulière sur le projet Lombok, d’une manière ou d’une 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 l'acceptent. Cela inclut les développeurs et tous les utilisateurs importants (par exemple, des sponsors officiels ou informels).
Vous mentionnez ces problèmes potentiels:
Flamewars va éclater dans le canal ## Java Freenode quand je le mentionne,
Facile. Ignorez/ne participez pas aux guerres de flammes ou abstenez-vous simplement de mentionner Lombok.
fournir des extraits de code va semer la confusion parmi les aides possibles,
Si la stratégie du projet consiste à utiliser Lombok, les assistants éventuels devront s’y habituer.
les gens vont se plaindre de l'absence de JavaDoc,
C'est leur problème. Personne de droit ne tente d'appliquer de manière rigide les règles de code source/de documentation de leur organisation à des logiciels open source tiers. L’équipe de projet doit être libre d’établir des normes de code source/de documentation du projet appropriées à la technologie utilisée.
(FOLLOWUP - Les développeurs de Lombok reconnaissent que le fait de ne pas générer de commentaires javadoc pour les méthodes de synthèse et de définition est un problème. S'il s'agit d'un problème majeur pour vos projets, une alternative consiste à créer et soumettez un correctif de Lombok pour résoudre ce problème.)
et les futurs commettants pourraient tout simplement tout supprimer de toute façon.
Ce n'est pas sur! Si la stratégie de projet convenue consiste à utiliser Lombok, les commettants qui dé-lodent gratuitement le code doivent être réprimandés et, si nécessaire, leurs droits d’engagement retirés.
Bien entendu, cela suppose que vous ayez le soutien des parties prenantes ... y compris des développeurs. Et cela suppose que vous soyez 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'ici, j'aime bien, mais un inconvénient que je n'ai pas vu mentionné est le support de refactoring.
Si vous avez une classe annotée avec @Data, elle générera pour vous les getters et les setters en fonction des noms de champs. Si vous utilisez l'un de ces accesseurs dans une autre classe, puis décidez que le champ est mal nommé, il ne trouvera pas d'utilisation de ces accesseurs et régleurs et remplacera l'ancien nom par le nouveau nom.
J'imagine que cela devrait se faire via un plug-in IDE et non via Lombok.
UPDATE (22 janvier '13)
Après avoir utilisé Lombok pendant 3 mois, je le recommande toujours pour la plupart des projets. Cependant, j’ai trouvé un autre inconvénient semblable à celui mentionné ci-dessus.
Si vous avez une classe, dites MyCompoundObject.Java qui a 2 membres, tous deux annotés avec @Delegate, dites myWidgets et myGadgets, lorsque vous appelez myCompoundObject.getThingies() depuis une autre classe , il est impossible de savoir s’il s’agit de déléguer à la Widget ou Gadget, car vous ne pouvez plus accéder à la source dans l’EDI.
Utiliser Eclipse "Generate Delegate Methods ..." vous offre les mêmes fonctionnalités, est tout aussi rapide et fournit des sauts de source. L'inconvénient est que cela encombre votre source avec du code passe-partout qui détourne l'attention des éléments importants.
UPDATE 2 (26 février 13)
Après 5 mois, nous utilisons toujours Lombok, mais j'ai quelques autres ennuis. L'absence d'un getter et d'un setter déclarés peut être agaçante lorsque vous essayez de vous familiariser avec le nouveau code.
Par exemple, si je vois une méthode appelée getDynamicCols() mais que 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 l’absence de plugin intelligent Lombok. Les obstacles comprennent:
- Manque de JavaDocs. Si javadoc le champ, j'espère que le getter et le setter hériteront de ce javadoc à travers la 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. C'est un problème de plugin.
- De toute évidence, vous ne pouvez pas définir de point d'arrêt dans un getter/setter à moins de générer ou de coder la méthode.
- REMARQUE: cette recherche de référence n’est pas un problème comme je le pensais au départ. Vous devez utiliser une perspective qui active la vue hiérarchique. Pas un problème pour la plupart des développeurs. Mon problème était que j'utilisais Mylyn, qui filtrait ma vue
Outline. Je n'ai donc pas vu les méthodes. Recherche de manque de références. Si je veux voir qui appellegetDynamicCols(args...), je dois générer ou coder le paramètre pour pouvoir rechercher des références.
UPDATE 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 sur une méthode générée par Lombok. A l'aide de la vue Outline, vous pouvez cliquer avec le bouton droit de la souris sur la méthode pour Toggle Method Breakpoint. Ensuite, lorsque vous appuyez sur le tiers, vous pouvez utiliser la vue de débogage Variables pour voir comment la méthode générée a nommé les paramètres (généralement identiques au nom du champ) et, enfin, utiliser la vue Breakpoints à droite. cliquez sur le partenaire et sélectionnez Breakpoint Properties... pour ajouter une condition. Agréable.
UPDATE 4 (16 août 2013)
Netbeans n’aime pas cela lorsque vous mettez à jour vos dépendances de Lombok dans votre Maven Pom. Le projet est toujours compilé, mais les fichiers sont signalés comme ayant des erreurs de compilation car ils ne peuvent pas voir les méthodes créées par Lombok. Effacer le cache Netbeans résout le problème. Vous ne savez pas s'il existe une option "Nettoyer le projet" comme dans Eclipse. Problème mineur, mais je voulais le faire savoir.
UPDATE 5 (17 janvier 2014)
Lombok ne joue pas toujours Nice avec Groovy, ou du moins le groovy-Eclipse-compiler. Vous devrez peut-être rétrograder votre version du compilateur. Maven Groovy et Java + Lombok
UPDATE 6 (26 juin 2014)
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 gênera. Vous serez peut-être mieux de ne jamais l'utiliser du tout.
UPDATE 7 (23 juillet '14)
Il s’agit d’une mise à jour intéressante car elle concerne directement la safety de l’adoption de Lombok à propos de laquelle l’opérateur s’est interrogé.
À partir de la version 1.1, l'annotation @Delegate a été rétrogradée en statut Expérimental. Les détails sont documentés sur leur site ( Lombok Delegate Docs ).
En réalité, si vous utilisiez cette fonctionnalité, vos options de sauvegarde sont limitées. Je vois les options comme:
- Supprimez manuellement les annotations
@Delegateet générez/codez manuellement le code de délégué. Ceci est un peu plus difficile si vous utilisiez des attributs dans l'annotation. - Delombok les fichiers qui ont l'annotation
@Delegateet peut-être ajouter dans les annotations que vous voulez. - Ne mettez jamais à jour Lombok ni ne maintenez une fourche (ou ne vivez pas avec des fonctionnalités expérimentales).
- Delombok tout votre projet et arrêtez d'utiliser Lombok.
Autant que je sache, Delombok n'a pas l'option de supprimer un sous-ensemble d'annotations ; c'est tout ou rien au moins pour le contexte d'un seul fichier. J'ai ouvert n ticket pour demander cette fonctionnalité avec des drapeaux Delombok, mais je ne m'attendrais pas à cela dans un proche avenir.
UPDATE 8 (20 oct '14)
Si c'est une option pour vous, Groovy offre la plupart des mêmes avantages que Lombok, auxquels s'ajoutent de nombreuses 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 .
UPDATE 9 (1 er septembre '15)
Lombok est toujours en cours activement maintenu et amélioré , ce qui augure bien pour le niveau de sécurité de l’adoption. Les annotations @ Builder font partie de mes nouvelles fonctionnalités préférées.
UPDATE 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 de Lombok pourrait constituer une solution au problème qu’ils tentaient 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) [remarque - vous pouvez le faire, mais cela nécessite juste un décompileur]
- Les hacks du compilateur sont non standard et fragiles
- "À notre avis, votre code n'est plus vraiment Java"
Je ne sais pas dans quelle mesure je suis d'accord avec leur évaluation. Et étant donné les inconvénients d'AutoValue décrits dans les diapositives, je resterai fidèle à Lombok (si Groovy n'est pas une option).
UPDATE 11 (8 février 16)
J'ai découvert Spring Roo en a annotations similaires . J'ai été un peu surpris de constater que Roo est encore une chose et que trouver de la documentation pour les annotations est un peu difficile. Le retrait n’a pas non plus l’air aussi facile que De-Lombok. Lombok semble être le choix le plus sûr.
UPDATE 12 (17 février 2016)
Tout en essayant de trouver des justifications sur la raison pour laquelle il est prudent de faire venir 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 - The 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 à un répertoire avec différents paramètres. C'est génial.
UPDATE 13 (4 oct '16)
Si ce genre de chose vous tient à cœur, Oliver Gierke estime qu'il est prudent de ajouter Lombok au Spring Data Rest .
UPDATE 14 (26 sept '17)
Comme indiqué par @ gavenkoa dans les commentaires sur la question des PO, Le support du compilateur JDK9 n'est pas encore disponible (numéro 985). Il semble également que ce ne sera pas une solution facile pour l’équipe de Lombok de se déplacer.
UPDATE 15 (26 mars '18)
Le journal des modifications de Lombok indique qu'à partir de la v1.16.20 " La compilation de Lombok sur JDK1.9 est désormais possible " même si # 985 est toujours ouvert.
Les modifications pour prendre en charge JDK9, cependant, ont nécessité certaines modifications radicales; tous isolés aux changements de configuration par défaut. C'est un peu inquiétant qu'ils aient introduit des changements radicaux, mais la version n'a modifié que le numéro de version "Incrémental" (passant de la v1.16.18 à la v1.16.20). Étant donné que cet article concernait la sécurité, si vous disposiez d'un système de compilation semblable à yarn/npm qui était automatiquement mis à niveau vers la dernière version incrémentielle, vous risqueriez un réveil brutal.
UPDATE 16 (9 janvier '19)
Il semble que les problèmes de JDK9 ont été résolus et Lombok fonctionne avec JDK10, et même JDK11 pour autant que je sache.
Un aspect de la sécurité qui me préoccupe est le fait que le journal des modifications de la v1.18.2 à la v1.18.4 répertorie deux éléments sous la forme BREAKING CHANGE !? Je ne suis pas sûr de savoir comment un changement radical se produit dans une mise à jour semver "patch". Peut-être un problème si vous utilisez un outil qui met à jour automatiquement les versions de correctif.
Allez-y et utilisez Lombok, vous pouvez éventuellement "supprimer" votre code par la suite http://projectlombok.org/features/delombok.html
Personnellement (et donc subjectivement), j'ai constaté que l'utilisation de Lombok rend mon code plus explicite sur ce que j'essaie d'atteindre par rapport aux implémentations IDE/propres 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 savoir quels champs sont évalués, que n'importe quelle implémentation IDE/own. Cela est particulièrement vrai lorsque vous ajoutez/supprimez régulièrement des champs.
Il en va de même pour l'annotation @ToString 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 l'appel ou non de super.toString().
Et encore une fois, en annotant une classe entière avec @Getter ou @Setter(AccessLevel.NONE) (et en remplaçant éventuellement les méthodes divergentes), il est immédiatement clair quelles méthodes seront disponibles pour les champs.
Les avantages vont encore et encore ..
Dans mon esprit, il ne s'agit pas de réduire le code, mais de communiquer clairement ce que vous souhaitez atteindre, plutôt que de devoir le comprendre à partir de Javadoc ou de ses 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 en ce sens qu'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 autre chose existent.
Le traitement des annotations s'effectue en une série de tours. À chaque tour, chacun a son tour de courir. Si de nouveaux fichiers Java sont trouvés à la fin du tour, un autre tour commence. De cette manière, 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é. Par conséquent, certains AP qui reposent sur du code lombok ne fonctionnent pas comme prévu. Cela a été une énorme source de douleur pour moi d'utiliser Mapstruct, et delombok-ing n'est pas une option utile car il détruit les numéros de ligne dans les journaux.
J'ai finalement piraté un script de compilation pour travailler à la fois avec Lombok et Mapstruct. Mais je veux laisser tomber lombok à cause de la façon dont il fonctionne - dans ce projet au moins. J'utilise lombok tout le temps dans d'autres choses.
J'ai lu des opinions sur le Lombok et je l'utilise dans certains projets.
Au premier contact avec Lombok, j'ai eu une mauvaise impression. Après quelques semaines, j'ai commencé à aimer ça. Mais au bout de quelques mois, je découvre beaucoup de petits problèmes d'utilisation. Donc, ma dernière impression sur Lombok n’est pas aussi positive.
Mes raisons de penser de cette façon:
- Dépendance du plug-in IDE . Le support IDE de Lombok se fait via des plugins. Même si vous travaillez bien la plupart du temps, vous êtes toujours pris en otage par ces plug-ins à conserver dans les futures versions des IDE et même la version linguistique (Java 10+ accélérera le développement du la langue). Par exemple, j'ai essayé de mettre à jour à partir d'Intellij IDE 2017.3 à 2018.1 et je ne pouvais pas le faire car il y avait un problème avec la version actuelle du plugin Lombok et j'ai besoin d'attendre que le plugin soit mis à jour ... Ceci Cela pose également un problème si vous souhaitez utiliser une solution plus alternative IDE qui ne prend pas en charge le plugin Lombok.
- Problème 'Trouver des usages'. . En utilisant Lombok, vous ne voyez pas les méthodes getter, setter, constructeur, constructeur, etc. générées. Donc, si vous prévoyez de découvrir quelles méthodes sont utilisées dans votre projet par votre IDE, vous ne pouvez pas le faire uniquement chercher la classe qui possède ces méthodes cachées.
- Si facile que les développeurs ne se soucient pas de casser l'encapsulation . Je sais que ce n'est pas vraiment un problème de Lombok. Mais j'ai constaté une plus grande tendance aux développeurs de ne plus contrôler les méthodes qui doivent être visibles ou non. Donc, souvent, ils copient et collent
@Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorannotations sans se demander quelles méthodes la classe doit réellement exposer. - Obssession du générateur ©. J'ai inventé ce nom (descendre, Martin Fowler). Blague à part, il est si facile de créer un générateur que même lorsqu'une classe n'a que deux paramètres, les développeurs préfèrent utiliser
@Builderà la place d'un constructeur ou d'une méthode de constructeur statique. Parfois, ils essaient même de créer un constructeur dans le constructeur lombok, créant ainsi des situations étranges telles queMyClass.builder().name("Name").build().create(). - Obstacles lors du refactoring . Si vous utilisez, par exemple, un
@AllArgsConstructoret que vous devez ajouter un paramètre supplémentaire au constructeur, le IDE ne peut pas vous aider à ajouter ce paramètre supplémentaire à tous les emplacements (la plupart du temps, des tests). ) qui instancient la classe. - Mélangez 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. Donc, 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 piratage de la langue.
Comme une autre réponse a dit, si vous êtes en colère à propos de la verbosité Java et que vous utilisez Lombok pour la gérer, essayez Kotlin.
Il existe également des risques de maintenance à long terme. Premièrement, je vous recommande de lire sur le fonctionnement réel de Lombok, par exemple. quelques réponses de ses développeurs ici .
Le site officiel contient également un liste des inconvénients , y compris cette citation de Reinier Zwitserloot:
C'est un hack total. Utilisation d'une API non publique. Présomption d'incantation (sachant qu'un processeur d'annotation s'exécutant dans javac obtiendra une instance de JavacAnnotationProcessor, qui est l'implémentation interne d'AnnotationProcessor (une interface), qui dispose donc de deux méthodes supplémentaires qui sont utilisées pour obtenir l'AST en direct) .
Sur Eclipse, c’est 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 une API standard, je l'aurais fait ainsi, mais vous ne pouvez pas. Néanmoins, pour ce que ça vaut, j'ai développé le plug-in Eclipse pour Eclipse v3.5 s'exécutant sur Java 1.6, et sans apporter de modifications, cela fonctionnait sous Eclipse v3.4 s'exécutant sur Java 1.5 ainsi, ce n'est pas complètement fragile.
En résumé, bien que Lombok puisse vous faire gagner un peu de temps de développement, s’il existe une mise à jour javac non compatible avec les versions antérieures (par exemple, une atténuation des vulnérabilités), Lombok risque de vous coincer avec une ancienne version de Java pendant que les développeurs luttent. mettre à jour leur utilisation de ces API internes. Que ce soit un risque sérieux dépend évidemment du projet.
J'ai utilisé Lombok dans presque tous mes projets pendant un an mais je l'ai malheureusement supprimé. Au début, c’était une méthode de développement très propre, mais la mise en place d’un environnement de développement pour les nouveaux membres de l’équipe n’est pas très simple et facile. Quand c'est devenu un mal de tête je l'ai juste enlevé. Mais c’est un bon travail et la mise en place nécessite plus de simplicité.
Je sais que je suis en retard, mais je ne peux pas résister à la tentation: quiconque aime Lombok devrait également jeter un coup d'œil à Scala. Beaucoup de bonnes idées que vous trouvez à Lombok font partie du langage Scala.
Sur votre question: il est nettement plus facile de faire essayer Lombok à vos développeurs que Scala. Essayez et s'ils l'aiment, essayez Scala.
Juste comme un disclaimer: J'aime aussi Java!
Quand j'ai montré le projet à mon équipe, l'enthousiasme était élevé, alors je pense que vous ne devriez pas avoir peur de la réaction de l'équipe.
En ce qui concerne le retour sur investissement, son intégration est simple et ne nécessite aucun changement de code dans sa forme de base. (ajouter juste une seule annotation à votre classe)
Enfin, si vous changez d’idée, vous pouvez exécuter le unlombok ou laisser votre IDE créer ces setters, getters et ctors (que je pense que personne ne demandera une fois qu’ils verront à quel point votre devient)
Voulait utiliser le @ToString de lombok, mais a rapidement fait face à des erreurs de compilation aléatoires lors de la reconstruction du projet dans Intellij IDEA. Il a fallu appuyer plusieurs fois sur la compilation avant que la compilation incrémentielle puisse aboutir.
Essayé les deux 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 temps meilleurs.
Mettre à jour
Le problème ne se produit qu'avec la compilation parallèle activée.
A déposé un problème: https://github.com/rzwitserloot/lombok/issues/648
Mettre à 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.
Mettre à jour
Je recommande fortement de passer de Java + Lombok à Kotlin si possible. Comme il a résolu toutes les questions Java que Lombok essaie de résoudre.
Mon point de vue sur Lombok est qu’il fournit simplement des raccourcis pour écrire du code bolilerplate Java.
En ce qui concerne l'utilisation de raccourcis pour l'écriture de code bolilerplate Java, je me baserais sur les fonctionnalités fournies par IDE - comme dans Eclipse, nous pouvons accéder au menu Source > Générer des Getters et des Setters pour générer des Getters et des Setters.
Je ne compterais pas sur une bibliothèque comme Lombok pour ceci:
- Il pollue votre code avec une couche indirectionnelle de syntaxe alternative (annotations read
@Getter,@Setter, etc.). Plutôt que d’apprendre une syntaxe alternative pour Java, je passerais à n’importe quel autre langage qui fournit nativement une syntaxe semblable à celle de Lombok. - Lombok nécessite l’utilisation d’un IDE pris en charge par Lombok pour fonctionner avec votre code. Cette dépendance présente un risque considérable pour tout projet non trivial. Le projet open source de Lombok dispose-t-il de suffisamment de ressources pour continuer à fournir un support pour différentes versions d'un large éventail de Java IDE disponibles?
- Le projet open source de Lombok dispose-t-il de suffisamment de ressources pour continuer à fournir un support pour les versions plus récentes de Java à venir?
- Je suis également inquiet que Lombok puisse créer des problèmes de compatibilité avec des frameworks/bibliothèques largement utilisés (tels que Spring, Hibernate, Jackson, JUnit, Mockito) qui fonctionnent avec votre code octet à l'exécution.
Dans l'ensemble, je ne préférerais pas "pimenter" mon Java avec Lombok.
J'ai rencontré un problème avec Lombok et Jackson CSV, lorsque j'ai marshalisé mon objet (bean Java) dans un fichier CSV, les colonnes étaient 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 lorsque je travaillais avec NetBeans 7.4, cela perturbait mes codes. Je dois supprimer Lombok dans tous les fichiers de mes projets. Il y a delombok, mais comment puis-je être sûr que cela ne ferait pas tout foirer? Je dois passer des jours à 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 ait causé d’importants problèmes, et que des travaux correctifs étaient en cours il ya une semaine. . Ma source pour cela est https://code.google.com/p/projectlombok/issues/detail?id=451 .