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

StackOverflow https://stackoverflow.com/questions/3852091

  •  27-09-2019
  •  | 
  •  

Question

Dans le cas où vous ne savez pas projet Lombok aide à certains des contrariétés de Java avec des trucs comme générer des accesseurs avec annotations et même simple, comme JavaBean génération @data. Il pourrait vraiment me aider, en particulier dans les 50 objets d'événements différents où vous avez jusqu'à 7 domaines différents qui doivent être construits et caché avec getters. Je pouvais retirer près d'un millier de lignes de code avec cela.

Cependant, je suis inquiet que dans le long terme, ce sera une décision regrettable. Flamewars éclateront dans le canal de ##Java Freenode quand je le mentionne, en fournissant des extraits de code confondra aides possibles, les gens se plaignent de manquer JavaDoc et futurs commiters pourraient tout simplement l'enlever tout de toute façon. Je voudrais vraiment profiter du positif, mais je suis inquiet pour le négatif.

: Est-il sûr d'utiliser Lombok sur tout projet, petit ou grand? Sont les effets positifs valent les négatifs?

Était-ce utile?

La solution

On dirait que vous avez déjà décidé que le projet Lombok vous donne d'importants avantages techniques pour votre nouveau projet proposé. (Pour être clair dès le départ, je n'ai pas vues particulières sur le projet Lombok, d'une façon ou l'autre.)

Avant d'utiliser Project Lombok (ou toute autre technologie de changement de jeu) dans certains projets (open source ou autrement), vous devez vous assurer que les parties prenantes du projet d'accord à ce sujet. Cela inclut les développeurs et les utilisateurs importants (par exemple les promoteurs formels ou informels).

Vous mentionnez ces problèmes potentiels:

  

GuerreDeMots va entrer en éruption dans le canal ## Java Freenode quand je le mentionne,

facile. Ignorer / ne participent pas aux discussions enflammées, ou de ne pas tout simplement de mentionner Lombok.

  

fournir des extraits de code confondra aides possibles,

Si la stratégie du projet est d'utiliser Lombok, alors les aides possibles devra se habituer.

  

les gens se plaignent de manquer JavaDoc,

C'est leur problème. Personne dans leur tente droit d'esprit à appliquer de manière rigide leur code source de l'organisation / règles de documentation à des tiers logiciels open source. L'équipe du projet devrait être libre de définir le code source du projet / normes de documentation appropriées à la technologie utilisée.

( FOLLOWUP -. Les développeurs Lombok reconnaissent que ne générant pas de commentaires Javadoc pour les méthodes getter et setter de synthèse est un problème si cela est un problème majeur pour votre projet (s), puis une autre solution consiste à créer et soumettre un patch Lombok pour y remédier.)

  

et futurs commiters pourraient tout simplement l'enlever tout de toute façon.

C'est pas! Si la stratégie du projet est convenu d'utiliser Lombok, comiteurs alors qui de-Lombok à titre gratuit le code devrait être réprimandé, et si nécessaire que leurs droits soient retirés commettre.

Bien sûr, cela suppose que vous avez buy-in des acteurs ... y compris les développeurs. Et il suppose que vous êtes prêt à faire valoir votre cause, et traiter correctement les voix dissidentes inévitables.

Autres conseils

Tout a commencé à utiliser aujourd'hui Lombok. Jusqu'à présent, je l'aime, mais un inconvénient je ne l'ai pas mentionné était le soutien refactoring.

Si vous avez une classe avec annotées @Data, il va générer les accesseurs pour vous sur la base des noms de champs. Si vous utilisez un de ces getters dans une autre classe, puis décider le champ est mal nommé, il ne trouvera pas les usages de ces accesseurs et remplacer l'ancien nom avec le nouveau nom.

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

Mise à jour (22 janvier '13) Après avoir utilisé Lombok pendant 3 mois, je vous recommande encore pour la plupart des projets. Je ne trouve cependant un autre inconvénient qui est similaire à celui indiqué ci-dessus.

Si vous avez une classe, par exemple MyCompoundObject.java qui a 2 membres, à la fois annoté avec @Delegate, myWidgets de dire et myGadgets, lorsque vous appelez myCompoundObject.getThingies() d'une autre classe, il est impossible de savoir si elle est déléguer au Widget ou Gadget parce que vous ne pouvez plus saut à la source au sein de l'IDE.

Utilisation de l'Eclipse « Générer des méthodes Déléguer ... » vous offre la même fonctionnalité, est tout aussi rapide et fournit des sauts source. L'inconvénient est qu'il Clutter source avec le code qui boilerplate détourner l'attention les choses importantes.

MISE À JOUR 2 (26 février '13) Au bout de 5 mois, nous utilisons encore Lombok, mais j'ai quelques autres contrariétés. L'absence d'un getter et setter déclaré peut se agaçant parfois 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 parle, j'ai quelques obstacles supplémentaires à sauter pour déterminer le but de cette méthode. Certains des obstacles sont Lombok, certains sont le manque d'un plug-in intelligent Lombok. Haies comprennent:

  • Le manque de JavaDocs. Si je javadoc le terrain, j'espère que le getter et setter hériterait que javadoc par l'étape de compilation Lombok.
  • Aller à la définition de la méthode me saute à la classe, mais pas la propriété qui a généré le getter. Ceci est un problème de plug-in.
  • Il est évident que vous n'êtes pas en mesure de mettre un point d'arrêt dans un getter / setter à moins que vous générez ou un code de la méthode.
  • NOTE: Cette référence recherche n'est pas une question que j'ai pensé qu'il était. Vous ne devez utiliser une perspective qui permet la vue Outline bien. Pas un problème pour la plupart des développeurs. Mon problème est que je me sers Mylyn qui filtrait mon avis de Outline, donc je ne vois pas les méthodes. Le manque de références rechercher. Si je veux voir qui appelle getDynamicCols(args...), je dois générer ou coder setter pour pouvoir rechercher des références.

Mise à jour 3 (7 mars '13) Apprendre à utiliser les différentes façons de faire les choses dans Eclipse I guess. Vous pouvez réellement mettre sur une méthode générée Lombok un point d'arrêt conditionnel (BP). Utilisation de la vue Outline, vous pouvez cliquer droit sur la méthode à Toggle Method Breakpoint. Ensuite, quand vous frappez la BP, vous pouvez utiliser la vue Variables débogage pour voir ce que la méthode générée nommé les paramètres (généralement le même que le nom du champ) et enfin, utiliser la vue Breakpoints un clic droit sur le BP et sélectionnez Breakpoint Properties... ajouter une condition. Nice.

Mise à jour 4 (16 août '13) Netbeans ne aime pas quand vous mettez à jour vos dépendances Lombok dans votre pom Maven. Le projet compile encore, mais les fichiers sont signalé pour avoir des erreurs de compilation, car il ne peut pas voir les méthodes Lombok est en train de créer. Effacement du cache Netbeans résout le problème. Je ne sais pas s'il y a une option « Clean Project » comme il est dans Eclipse. Un problème mineur, mais je voulais le faire connaître.

Mise à jour 5 (17 janvier '14) Lombok ne joue pas toujours agréable avec Groovy, ou tout au moins la groovy-eclipse-compiler. Vous pourriez avoir à rétrograder votre version du compilateur. Maven Groovy

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, il agacer la pisse sur vous. Vous pouvez être mieux juste ne jamais l'utiliser du tout.

Mettre à Jour 7 (23 juillet '14) Ceci est un peu une mise à jour intéressante car elle répond directement sécurité de l'adoption Lombok que l'OP a demandé au sujet.

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

La chose est, si vous utilisez cette fonction, vos options de Backout sont limitées. Je vois les options:

  • supprimer manuellement les annotations @Delegate et générer / handcode le code délégué. Ceci est un peu plus difficile si vous utilisez des attributs au sein de l'annotation.
  • Delombok les fichiers qui ont l'annotation @Delegate et peut-être rajouter dans les annotations que vous voulez.
  • Ne jamais mettre à jour Lombok ou de maintenir une fourchette (ou en temps réel avec l'utilisation des fonctions expérientiels).
  • Delombok l'ensemble de votre projet et cesser d'utiliser Lombok.

Pour autant que je peux dire, Delombok ne dispose pas d'une option pour supprimer un sous-ensemble d'annotations ; il est tout ou rien du moins dans le contexte d'un seul fichier. J'ai ouvert un billet pour demander cette fonctionnalité avec des drapeaux Delombok, mais Je n'attendre à ce que dans un avenir proche.

Mise à jour 8 (20 octobre '14) Si c'est une option pour vous, la plupart des offres Groovy les mêmes avantages de Lombok, plus une charge de bateau d'autres caractéristiques, y compris @Delegate . Si vous pensez que vous aurez du mal à vendre l'idée aux pouvoirs en place, jetez un oeil à l'annotation @CompileStatic ou @TypeChecked pour voir si cela peut aider votre cause. En fait, l'objectif principal de la libération était super 2,0 de sécurité statique.

Mise à jour 9 (1 septembre '15) Lombok est toujours en cours activement entretenu et amélioré , ce qui augure bien au niveau de la sécurité de l'adoption. @Builder annotations est l'une de mes nouvelles fonctions préférées.

UPDATE 10 (17 novembre '15) Cela peut ne pas sembler directement lié à la question de l'OP, mais le partage de la valeur. Si vous êtes à la recherche d'outils pour vous aider à réduire la quantité de code boilerplate que vous écrivez, vous pouvez également consulter Google Auto - en particulier AutoValue . Si vous regardez leur pont coulissant , la la liste Lombok comme une solution possible au problème qu'ils tentent de résoudre. Les inconvénients qu'ils liste Lombok sont:

  • Le code inséré est invisible (vous ne pouvez pas « voir » les méthodes qu'il génère) [ndlr - vous pouvez réellement, mais juste requires un décompilateur]
  • Les hacks du compilateur ne sont pas standard et fragile
  • "À notre avis, votre code n'est plus vraiment Java"

Je ne sais pas à quel point je suis d'accord avec leur évaluation. Et étant donné les inconvénients de AutoValue qui sont documentées dans les coulisses, je vais coller avec Lombok (si Groovy est pas une option).

Mise à jour 11 (8 février '16) J'ai trouvé Spring Roo a une annotations similaires . J'étais un peu surpris de découvrir Roo est toujours une chose et trouver la documentation pour les annotations est un peu rugueux. L'élimination aussi ne semble pas aussi facile que de-lombok. Lombok semble que le choix plus sûr.

Mettre à Jour 12 (17 février '16) Tout en essayant de trouver des justifications pour lesquelles il est sûr d'apporter à Lombok pour le projet Je travaille actuellement sur, j'ai trouvé un morceau d'or qui a été ajoutée avec v1.14 - Le Configuration du système ! Ceci est signifie que vous pouvez configurer un projet de dé-autoriser certaines caractéristiques que votre équipe juge dangereuse ou indésirable. Mieux encore, il peut aussi créer le répertoire config spécifique avec des paramètres différents. Ceci est IMPRESSIONNANT.

Mise à jour 13 (4 octobre '16) Si ce genre de chose qui compte pour vous, Oliver Gierke a estimé qu'il était sûr de ajouter Lombok au printemps de données Rest .

Mettre à Jour 14 (26 septembre '17) Comme l'a souligné @gavenkoa dans les commentaires sur la question des postes d'observation, JDK9 support du compilateur est pas encore disponible (numéro 985). Il semble aussi que ça ne va pas être une solution facile pour l'équipe Lombok pour se déplacer.

Mise à jour 15 (26 mars '18) Le changelog Lombok indique que de v1.16.20 " Compiling sur lombok JDK1.9 est maintenant possible " même si # 985 est toujours ouverte.

changements tenant compte JDK9, cependant, a nécessité des changements de rupture; tous isolés à des changements dans les valeurs par défaut de configuration. Il est un peu au sujet de leur introduction rupture des changements, mais la seule version cogné le numéro de version « incrémental » (allant de v1.16.18 à v1.16.20). Depuis ce poste était de la sécurité, si vous aviez un yarn/npm comme système de construction qui automatiquement mis à jour à la dernière version incrémentale, vous pourriez être dans un réveil brutal.

UPDATE 16 (9 janvier '19)

Il semble les problèmes ont été résolus JDK9 et Lombok travaille avec JDK10, et même jdk11 aussi loin que je peux dire.

Une chose que je remarque cependant que concernait d'un aspect de la sécurité est le fait que le journal des modifications allant de v1.18.2 aux listes de v1.18.4 deux éléments tels que BREAKING CHANGE !? Je ne sais pas comment un changement de rupture se produit dans une mise à jour semver « patch ». Peut-être un problème si vous utilisez un outil que les versions de patch auto-mises à jour.

Allez-y et l'utilisation 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 Lombok rend mon code plus expressif sur ce que je suis en train de réaliser par rapport aux IDE / propres implémentations de méthodes complexes telles que hashcode et égaux.

Lorsque vous utilisez 

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

il est beaucoup plus facile de garder Equals et HashCode cohérente et garder une trace des champs sont évalués, que tout IDE / propre implémentation. Cela est particulièrement vrai lorsque vous êtes encore l'ajout / suppression des champs régulièrement.

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 de getters ou l'accès sur le terrain et si oui ou non à l'appel super.toString().

Et encore en annotant une classe entière avec @Getter ou @Setter(AccessLevel.NONE) (et en remplaçant le cas échéant des méthodes divergentes) il est clair immédiatement quelles méthodes seront disponibles pour les champs.

Les avantages et continuer ..

Dans mon esprit, ce n'est pas à réduire le code, mais de communiquer clairement ce que vous désirez atteindre, plutôt que d'avoir à le comprendre à partir Javadoc ou mises en œuvre. Le code réduit est tout simplement plus facile à repérer toutes les implémentations méthode de divergence.

Lombok est grande, mais ...

Lombok enfreint les règles de traitement des annotations, en ce qu'elle 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 attendent les getters / setters ou tout autre chose d'exister.

exécute le traitement d'annotation dans une série de tours. A chaque tour, chacun obtient un tour à courir. Si tous les nouveaux fichiers java se trouvent après le tour est terminé, un autre tour commence. De cette façon, l'ordre des processeurs d'annotation n'a pas d'importance si elles ne génèrent que de nouveaux fichiers. Étant donné que lombok ne génère pas de nouveaux fichiers, pas de nouvelles séries sont lancées si certains AP qui repose sur le code ne fonctionne lombok comme prévu. Ce fut une énorme source de douleur pour moi tout en utilisant mapstruct et delombok-ing est pas une option utile car elle détruit vos numéros de ligne dans les journaux.

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

Il y a des risques d'entretien à long terme ainsi. Tout d'abord, je vous recommande de lire sur la façon dont fonctionne réellement Lombok, par exemple des réponses de ses développeurs .

Le site officiel contient également un , y compris cette citation de Reinier Zwitserloot:

  

Il est un hack au total. Utilisation de l'API non publiques. casting présomptueuse (savoir   qu'un processeur d'annotation en cours d'exécution dans javac obtenir une instance de   JavacAnnotationProcessor, qui est la mise en œuvre interne   AnnotationProcessor (une interface), ce qui arrive de façon à avoir un couple   des méthodes supplémentaires qui sont utilisés pour obtenir à l'AST en direct).

     

Sur éclipse, il est sans doute le pire (et encore plus robuste) - un agent java   est utilisée pour injecter du code dans la grammaire de l'éclipse et la classe de l'analyseur,   qui est d'une API entièrement sûr non publiques et totalement hors limites.

     

Si vous pouvez faire ce que fait avec l'API lombok standard, je l'aurais fait   cette façon, mais vous ne pouvez pas. Pourtant, pour ce que ça vaut, j'ai développé la   plugin Eclipse pour Eclipse v3.5 fonctionnant sur Java 1.6, et sans   toute modification, il a travaillé sur Eclipse v3.4 fonctionnant sur Java 1.5 comme   eh bien, il est donc pas tout à fait fragile.

En résumé, alors que Lombok peut vous faire économiser un peu de temps de développement, s'il y a une mise à jour de javac non rétrocompatible (par exemple, une réduction de la vulnérabilité) Lombok pourrait obtenir vous coincé avec une ancienne version de Java alors que les développeurs se démènent pour mettre à jour leurs l'utilisation de ces API internes. Que ce soit un risque sérieux dépend évidemment du projet.

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

Eh bien, dans le premier contact avec Lombok j'ai eu une mauvaise impression. Après quelques semaines, j'ai commencé à l'aimer. Mais après quelques mois que je figure sur beaucoup de petits problèmes à l'utiliser. Donc, mon impression finale au sujet de Lombok est pas positif.

Mes raisons de penser ainsi:

  • plug-in IDE dépendance . Le support IDE pour Lombok est grâce à des plugins. Même les bons de travail ins plupart du temps, vous êtes toujours un otage de ce plug-ins à maintenir dans les futures versions des ides et même la version (Java 10+ va accélérer le développement de la langue). Par exemple, j'ai essayé de mettre à jour de Intellij IDE 2017,3 à 2018,1 et je ne pouvais pas le faire parce qu'il ya un problème sur la lombok la version plug-in réelle et je dois attendre le plugin être mis à jour ... C'est aussi un problème si vous souhaite utiliser un IDE plus alternative qui n'ont pas de support des plugins Lombok.
  • Trouvez des usages de problème. . L'utilisation Lombok vous ne voyez pas les getter générés, setter, constructeur, méthodes de constructeur, etc Donc, si vous prévoyez de savoir ce que ces méthodes sont utilisées dans votre projet par votre IDE, vous ne pouvez pas faire seulement la recherche de la classe qui possède ces méthodes cachées.
  • Tellement 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 aux développeurs de contrôler plus ce que les méthodes doivent être visibles ou non. Ainsi, plusieurs fois ils sont tout simplement copier et de coller des annotations @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor sans penser à ce que les méthodes de la classe vraiment besoin d'exposer.
  • Builder Obssession ©. J'ai inventé ce nom (descendre, Martin Fowler). Blagues à part, un constructeur est si facile de créer que même lorsqu'une classe ont seulement deux paramètres les développeurs préfèrent utiliser @Builder au lieu de constructeur ou une méthode constructeur statique. Parfois, ils tentent même de créer un constructeur à l'intérieur du lombok Builder, ce qui crée des situations étranges comme MyClass.builder().name("Name").build().create().
  • obstacles lorsque refactoring . Si vous utilisez, par exemple, un @AllArgsConstructor et le besoin d'ajouter un paramètre plus sur le constructeur, l'IDE ne peut pas vous aider à ajouter ce paramètre supplémentaire dans tous les lieux (la plupart du temps, tests) qui sont instancié avec la classe.
  • Mix 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. Alors, vous verrez ces deux approches mixtes dans votre code. On se habitue à cela après un certain temps, mais se sent comme un hack sur la langue.

Comme une autre réponse dit, si vous êtes en colère à propos de Java verbosité et utilisez Lombok pour y faire face, essayez Kotlin.

Je sais que je suis en retard, mais je ne peux pas résister à la tentation: tout le monde goût Lombok devrait aussi jeter un oeil à Scala. Beaucoup de bonnes idées que vous trouvez à Lombok font partie de la langue Scala.

Sur votre question: il est certainement plus facile d'obtenir vos développeurs essayant Lombok que Scala. Faites un essai et si ça leur plaît, essayez Scala.

Tout comme un avertissement: Je aime Java aussi

J'ai utilisé Lombok dans presque tous mes projets pour un an, mais malheureusement enlevé. Au début, il était une façon très propre du développement, mais la mise en place de l'environnement de développement pour les nouveaux membres de l'équipe est pas très facile et simple. Quand il est devenu un mal de tête que je viens enlevé. Mais il est un bon travail et a besoin de plus de simplicité à la 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, il est un clin d'oeil à intégrer, et ne nécessite aucun changement dans sa forme de base de code. (Simple ajout d'une seule annotation à votre classe)

  • Enfin, si vous changez d'avis, vous pouvez exécuter le unlombok, ou laissez votre IDE créer ces setters, getters et cteurs, (que je pense que personne ne vous demandera une fois qu'ils voient comment effacer votre POJO devient)

Voulu au @ToString de l'utilisation lombok mais des erreurs de compilation aléatoire bientôt rencontrés sur le projet de reconstruction dans IntelliJ IDEA. Nous avons dû frapper à plusieurs reprises avant de compilation compilation incrémentale pourrait compléter 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 plug-in lombok sous jdk 1.6.0_39 et 1.6.0_45.

Nous avons dû copier manuellement les méthodes générées à partir des sources delomboked et de mettre lombok en attente jusqu'à ce que des temps meilleurs.

Mise à jour

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

Filed un problème: https://github.com/rzwitserloot/lombok/issues/648

Mise à jour

  

mplushnikov a commenté le 30 janv 2016:

     

Une version plus récente de Intellij   n'a pas plus ces questions. Je pense qu'il peut être fermé ici.

Mise à jour

Je recommande fortement à passer de Java + Lombok Kotlin si possible. Comme il a résolu à partir du sol toutes les questions que Java Lombok essaie de contourner.

Mon point de vue sur Lombok est qu'il fournit simplement des raccourcis pour l'écriture de code Java bolilerplate.
Quand il vient à l'aide de raccourcis pour écrire bolilerplate code Java, je compter sur ces fonctionnalités fournies par IDE - comme dans Eclipse, nous pouvons aller au menu Source> Générer accesseurs et de mutateurs pour générer des accesseurs
. Je ne voudrais pas compter sur une bibliothèque comme Lombok pour cela:

  1. Il pollue votre code avec une couche d'indirection de syntaxe alternative (lecture de @Getter, @Setter, etc. annotations). Plutôt que d'apprendre une autre syntaxe pour Java, je passer à une autre langue qui fournit nativement Lombok comme la syntaxe.
  2. Lombok nécessite l'utilisation d'un Lombok soutenu IDE au travail avec votre code. Cette dépendance présente un risque considérable pour tout projet non trivial. Le projet Lombok open source ont suffisamment de ressources pour continuer à fournir un soutien pour les différentes versions d'un large éventail de disponibles? Java IDE
  3. Est-ce que le projet Lombok open source ont suffisamment de ressources pour continuer à fournir un soutien pour les nouvelles versions de Java qui vont venir à l'avenir?
  4. Je me sens aussi nerveux que Lombok peuvent poser des problèmes de compatibilité avec les cadres / bibliothèques largement utilisés (comme Spring, Hibernate, Jackson, JUnit, Mockito) que le travail avec votre code d'octet lors de l'exécution.

Dans l'ensemble, je ne préfère « pimenter » mon Java avec Lombok.

J'ai rencontré un problème avec Lombok et Jackson CSV , quand je marshalized mon objet (java bean) dans un fichier CSV, les colonnes où dupliquées, puis j'ai enlevé Lombok de annotation @data et marshalizing bien travaillé.

Je le recommande pas. Je l'habitude de l'utiliser, mais quand je travaille avec NetBeans 7.4 il a été déconner mes codes. J'ai à supprimer dans tous lombok fichiers dans mes projets. Il y a delombok, mais comment puis-je être sûr qu'il ne vis mes codes. Je dois juste coules des jours supprimer lombok et retour aux styles Java ordinaires. Je viens trop épicé ...

Je n'ai pas essayé d'utiliser Lombok encore - il est / était sur ma liste, mais il semble que si Java 8 a causé des problèmes importants pour elle, et les travaux de réparation était encore en cours à partir de il y a une semaine. Ma source qui est https://code.google.com/p/ projectlombok / questions / détail? id = 451 .

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top