Ist es sicher, Projekt Lombok zu benutzen? [geschlossen]

https://stackoverflow.com/questions/3852091

java
lombok

27-09-2019
|

Frage

Falls Sie nicht wissen, Projekt Lombok mit einigen der Belästigungen von Java mit Sachen hilft wie Getter und Setter mit Anmerkungen zu erzeugen und sogar einfache JavaBean wie Generation mit @data . Es könnte mir wirklich helfen, vor allem in 50 verschiedenen Ereignisobjekten in dem Sie bis zu 7 verschiedenen Feldern auf, dass Bedarf mit Getter aufgebaut und versteckt werden. Ich kann fast tausend Zeilen Code mit diesem entfernen.

Aber ich bin besorgt, dass auf lange Sicht wird es eine bedauernden Entscheidung sein. Flamewars wird im ##Java Freenode Kanal ausbrechen, wenn ich es zu erwähnen, mögliche Helfer verwirren Code-Snippets bietet, Leute beschweren sich über JavaDoc fehlt, und zukünftige Committer könnte einfach alles sowieso entfernen. Ich würde wirklich die positive genießen, aber ich bin über die negativen besorgt.

So: Ist es sicher, Lombok für jedes Projekt, ob klein oder groß zu bedienen? Sind der positive Wert Effekte der Negativ?

Lösung

Es klingt wie Sie bereits entschieden haben, dass Projekt Lombok bietet Ihnen erhebliche technische Vorteile für die vorgeschlagenen neuen Projekt. (Um von Anfang an klar, ich habe keinen besonderen Blick auf Projekt Lombok, die eine oder die andere.)

Bevor Sie Project Lombok (oder andere bahnbrechende Technologie) in einem Projekt (Open Source oder andere weisen), müssen Sie sicherstellen, dass das Projekt Beteiligten damit einverstanden ist. Dazu gehört auch die Entwickler und alle wichtigen Benutzer (zum Beispiel formelle oder informelle Sponsoren).

Sie erwähnen diese potenziellen Probleme:

Flamewars in dem ## Java Freenode Kanal ausbrechen wird, wenn ich es zu erwähnen,

Einfach. Ignorieren / beteiligen sich nicht an den Flamewars oder einfach unterlassen, Lombok zu erwähnen.

Code Bereitstellung Schnipsel werden mögliche Helfer verwirren,

Wenn die Projektstrategie ist Lombok zu verwenden, dann die möglichen Helfer müssen sich daran gewöhnen.

werden die Leute beschweren sich über JavaDoc fehlt,

Das ist ihr Problem. Niemand bei klarem Verstand versucht gilt starr ihre Organisation Quellcode / Dokumentation Regeln für Fremd Open-Source-Software. Das Projektteam sollte Set-Projekt Quellcode / Dokumentationsstandards frei sein, die die Technologie geeignet sind, verwendet werden.

( Followup . - Die Lombok Entwickler erkennen, dass nicht zu erzeugen javadoc Kommentare für synthetisierte Getter und Setter-Methoden ist ein Problem, wenn dies ein großes Problem für Ihr Projekt (s), dann eine Alternative ist, erstellen und Lombok Patch-Adresse einreichen dieser.)

und Zukunft Committer könnte es nur entfernen Sie alle sowieso.

Das ist nicht auf! Wird die vereinbarte Projektstrategie Lombok zu verwenden ist, Committer dann die grundlos de-Lombok sollte der Code gezüchtigt werden und, falls erforderlich ihre begehen Rechte entzogen.

Natürlich setzt dies voraus, dass Sie haben Buy-in von den Beteiligten ... einschließlich der Entwickler. Und es wird davon ausgegangen, dass Sie Ihre Ursache sind bereit, zu argumentieren, und in geeigneter Weise die unvermeidlichen Gegenstimmen zu behandeln.

Andere Tipps

Gerade erst begonnen heute Lombok mit. Bisher Ich mag es, aber ein Nachteil ich nicht erwähnt habe sehen war Unterstützung Refactoring.

Wenn Sie eine Klasse mit @Data kommentiert haben, wird es die Getter und Setter für Sie generieren, basierend auf den Feldnamen. Wenn Sie eine dieses Getter in einer anderen Klasse verwenden, entscheidet dann das Feld schlecht benannt ist, wird es nicht Verwendungen dieser Getter und Setter finden und die alten Namen mit dem neuen Namen ersetzen.

Ich könnte mir vorstellen, das über einen IDE-Plug-in und nicht über Lombok getan werden müsste.

UPDATE (22. Januar '13)
Lombok für 3 Monate nach der Verwendung, empfehle ich es nach wie vor für die meisten Projekte. Ich habe jedoch finden einen weiteren Nachteil, der dem ähnlich ist, der oben aufgeführt ist.

Wenn Sie eine Klasse haben, sagen MyCompoundObject.java, die zwei Mitglieder hat, kommentierte beide mit @Delegate, sagen wir myWidgets und myGadgets, wenn Sie myCompoundObject.getThingies() von einer anderen Klasse nennen, ist es unmöglich zu wissen, ob es auf die Widget oder Gadget ist zu delegieren, weil Sie kann nicht mehr Sprung innerhalb der IDE-Quelle.

Mit dem Eclipse „Gene Delegatmethoden ...“ bietet Ihnen die gleiche Funktionalität, ist ebenso schnell und bietet Quelle Springen. Der Nachteil ist, es unübersichtlich Ihre Quelle mit Standardcode, der den Fokus weg von den wichtigen Sachen nehmen.

UPDATE 2 (26. Februar '13)
Nach 5 Monaten, verwenden wir noch Lombok, aber ich habe einige andere Belästigungen. Das Fehlen eines deklarierten Getter & Setter kann manchmal ärgerlich, wenn Sie versuchen, sich mit neuen Code vertraut zu machen.

Zum Beispiel, wenn ich eine Methode namens getDynamicCols() sehen, aber ich weiß nicht, worum es geht, ich habe einige zusätzliche Hürden den Zweck dieser Methode zu bestimmen, zu springen. Einige der Hürden sind Lombok, einige sind das Fehlen eines Lombok Smart Plug-ins. Hürden sind:

Mangelnde JavaDocs. Wenn ich javadoc das Feld, würde ich die Getter und Setter hoffen würde, dass javadoc durch den Schritt Lombok Kompilation erben.
Wechseln zu Methodendefinition springt mir in die Klasse, aber nicht die Eigenschaft, dass die Getter erzeugt. Dies ist eine Plugin Ausgabe.
Offensichtlich sind Sie nicht in der Lage, einen Haltepunkt in einer Getter / Setter zu setzen, wenn Sie generieren oder Code die Methode.
Hinweis: Diese Referenzsuche ist kein Problem, da ich zuerst dachte, es wäre. Sie brauchen eine Perspektive zu verwenden, der allerdings die Gliederungsansicht ermöglicht. Kein Problem für die meisten Entwickler. Mein Problem war, ich bin mit Mylyn, die meine Outline Ansicht sickerte, so dass ich nicht die Methoden sah. Mangelnde Referenzen suchen. Wenn ich sehen will, wer anruft getDynamicCols(args...), muss ich generieren oder Code die Setter in der Lage sein nach Referenzen zu suchen.

UPDATE 3 (7. März '13)
Das Erlernen der verschiedenen Möglichkeiten, die Dinge in Eclipse Ich denke, zu verwenden. Sie können tatsächlich einen bedingten Haltepunkt (BP) auf einem Lombok erzeugt Verfahren eingestellt. Mit Hilfe der Outline Ansicht können Sie mit der rechten Maustaste auf die Methode Toggle Method Breakpoint. Dann, wenn Sie die BP treffen, können Sie das Debuggen Variables Ansicht verwenden, um zu sehen, was die erzeugte Methode die Parameter genannt (in der Regel der gleiche wie der Feldname) und schließlich, verwenden Sie die Breakpoints Hinblick auf Rechtsklick auf den BP und wählen Sie Breakpoint Properties... hinzufügen ein Zustand. Nizza.

UPDATE 4 (16. August '13)
Netbeans mag es nicht, wenn Sie Ihre Lombok Abhängigkeiten in Ihrem Maven pom aktualisieren. Das Projekt stellt nach wie vor, aber die Dateien für mit Kompilierungsfehlern erhalten gekennzeichnet, weil es nicht die Methoden sehen Lombok schafft. die Netbeans-Cache zu löschen behebt das Problem. Nicht sicher, ob es eine „Clean Project“ Option ist wie es in Eclipse ist. Minor Problem, aber wollte es bekannt machen.

UPDATE 5 (17. Januar '14)
Lombok nicht immer schön mit Groovy spielen, oder zumindest die groovy-eclipse-compiler. Möglicherweise müssen Sie Ihre Version des Compilers degradieren. Maven Groovy und Java + Lombok

UPDATE 6 (26. Juni '14)
Ein Wort der Warnung. Lombok ist leicht süchtig und wenn Sie an einem Projekt arbeiten, wo Sie es aus irgendeinem Grund nicht verwendet werden kann, wird es die Pisse aus dir ärgern. Sie können besser dran, nur nie es überhaupt verwendet wird.

UPDATE 7 (23. Juli '14)
Dies ist ein bisschen ein interessantes Update, da sie direkt die Sicherheit Adressen von Lombok Annahme, dass die OP fragte nach.

Ab v1.14, die @Delegate Anmerkung zu einem experimentellen Status zurückgestuft worden. Die Details sind auf ihrer Website dokumentiert ( Lombok Delegate Docs ).

Die Sache ist, wenn Sie diese Funktion verwendet haben, sind Ihre backout Optionen begrenzt. Ich sehe die Optionen wie:

manuell entfernen @Delegate Anmerkungen und generieren / handcode den Delegaten Code. Dies ist ein wenig schwieriger, wenn Sie wurden Attribute innerhalb der Anmerkung verwendet wird.
Delombok die Dateien, die die @Delegate Annotation haben und vielleicht in den Anmerkungen hinzufügen zurück, die Sie wollen zu tun.
Nie Lombok aktualisieren oder eine Gabel (oder Live mit der Verwendung von Erfahrungs Funktionen) halten.
Delombok Ihr gesamtes Projekt und Stopp mit Lombok.

Soweit ich das beurteilen kann, Delombok keine Möglichkeit, eine Teilmenge von Annotationen zu entfernen; es ist alles oder nichts zumindest für den Rahmen einer einzigen Datei. Ich öffnete ein Ticket diese Funktion mit Delombok Flaggen zu beantragen, aber ich würde nicht erwarten, dass in der nahen Zukunft.

UPDATE 8 (20. Oktober '14)
Wenn es eine Option für Sie, Groovy bietet meisten die gleichen Vorteile von Lombok, plus ein Boot Belastung von anderen Funktionen, einschließlich @Delegate . Wenn Sie denken, werden Sie eine harte Zeit haben, um die Idee zu den Kräften, die den Verkauf sein, werfen Sie einen Blick auf die @CompileStatic oder @TypeChecked Anmerkung zu sehen, ob das Ihre Ursache helfen. In der Tat, der primäre Fokus des Release Groovy 2.0 war die statische Sicherheit .

UPDATE 9 (1. September '15)
Lombok wird noch aktiv gepflegt und erweitert , die ein gutes Omen auf das Sicherheitsniveau der Annahme. Die @Builder Anmerkungen ist eine meiner Lieblings neuen Features.

UPDATE 10 (17. November '15)
Dies kann nicht direkt an den OP Frage im Zusammenhang erscheinen, aber es wert. Wenn Sie sich für Werkzeuge, um Hilfe zu suchen reduzieren Sie die Menge an vorformulierten Code, den Sie schreiben, können Sie auch href="https://github.com/google/auto" rel="noreferrer"> Google Auto - insbesondere Autovalue . Wenn man sich ihre slide deck , die Liste Lombok als eine mögliche Lösung für das Problem, das sie zu lösen versuchen. Die Nachteile sie für Lombok Liste sind:

Der eingegebene Code ist unsichtbar (man kann nicht „sehen“, die die Methoden erzeugt er) [ed note - tatsächlich können Sie, aber es nur requires Decomplirer]
Die Compiler-Hacks sind Nicht-Standard und zerbrechlich
"Aus unserer Sicht, Ihr Code ist nicht mehr wirklich Java"

Ich bin mir nicht sicher, wie viel ich mit ihrer Bewertung übereinstimmen. Und die Nachteile der Autovalue gegeben, die in den Folien dokumentiert sind, werde ich mit Lombok kleben (wenn Groovy ist keine Option).

UPDATE 11 (8. Februar '16)
Ich fand heraus, Frühling Roo einige ähnliche Anmerkungen . Ich war ein wenig überrascht Roo, um herauszufinden, ist immer noch eine Sache und für die Anmerkungen Dokumentation zu finden, ist ein wenig rau. Entfernung sieht auch nicht so einfach, wie de-lombok. Lombok scheint, wie die sicherere Wahl.

UPDATE 12 (17. Februar '16)
Bei dem Versuch, für mit Rechtfertigungen zu kommen, warum es ist sicher für das Projekt in Lombok bringen arbeite ich zur Zeit an, fand ich ein Stück Gold, das mit v1.14 hinzugefügt wurde - die Configuration System ! Dies ist eine Einrichtung Sie ein Projekt zu dis-allow bestimmte Funktionen konfigurieren können, dass Ihr Team unsichere oder unerwünschte hält. Noch besser wäre es, kann es auch Verzeichnis spezifische Konfiguration mit verschiedenen Einstellungen erstellen. Das ist genial.

UPDATE 13 (4. Oktober '16)
Wenn diese Art der Sache ist für Sie wichtig, Oliver Gierke fühlte es war sicher hinzufügen Lombok Spring Data Ruhe .

UPDATE 14 (26. September '17)
Wie von @gavenkoa in den Kommentaren auf der OPs Frage, ist JDK9 Compiler-Unterstützung noch nicht verfügbar (Ausgabe # 985). Es klingt auch wie es wird nicht eine einfache Lösung sein für das Team Lombok herum zu erhalten.

UPDATE 15 (26. März '18)
Die Lombok Changelog zeigt, wie der v1.16.20 " compilieren lombok auf JDK1.9 ist nun möglich, " obwohl # 985 noch offen ist.

Änderungen an JDK9 zubringen, erforderte jedoch einige Bruch Änderungen; alle Änderungen in der Konfigurationsstandardwerte isoliert. Es ist ein wenig über, dass sie brechen Änderungen eingeführt, aber die Version nur die „Incremental“ Versionsnummer (geht von v1.16.18 zu v1.16.20) gestoßen. Da dieser Beitrag über die Sicherheit war, wenn Sie ein yarn/npm wie Build-System hatte, dass automatisch auf die neueste Version aktualisiert inkrementelle, könnten Sie in ein böses Erwachen sein.

UPDATE 16 (9. Januar '19)

Es scheint, die JDK9 Probleme behoben wurden und Lombok arbeitet mit JDK10 und jdk11 sogar so weit, wie ich kann sagen.

Eine Sache, die ich aber, dass bemerkt wurde aus einem Sicherheitsaspekt in Bezug auf die Tatsache, dass das Protokoll von v1.18.2 zu v1.18.4 Listen zwei Elemente als BREAKING CHANGE gehen ändern !? Ich bin mir nicht sicher, wie ein Bruch Änderung eines semver „Patch“ Update passiert. Könnte ein Problem sein, wenn Sie ein Werkzeug, die automatische Updates Patch-Versionen verwenden.

Gehen Sie voran und verwenden Lombok, können Sie, wenn nötig „delombok“ Code danach http://projectlombok.org/features/delombok .html

Persönlich (und daher subjektiv) Ich habe festgestellt, dass die Verwendung Lombok macht meinen Code ausdruck über das, was ich versuche, wenn sie auf IDE / eigene Implementierungen von komplizierten Verfahren wie hashcode & equals im Vergleich zu erreichen.

Bei der Verwendung von

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

es ist viel einfacher zu halten Equals & HashCode konsistente und zu verfolgen, welche Felder ausgewertet werden, als jede IDE / eigene Implementierung. Dies gilt insbesondere, wenn Sie immer noch das Hinzufügen / Entfernen von Feldern regelmäßig.

Das gleiche gilt für die @ToString Annotation und deren Parameter, die das gewünschte Verhalten in Bezug auf inbegriffen / ausgeschlossen Felder, Verwendung von Getter oder Feldzugriff und ob oder nicht Anruf super.toString() klar kommunizieren.

Und wieder durch eine ganze Klasse mit @Getter oder @Setter(AccessLevel.NONE) Anmerkungen versehen (und überschreiben gegebenenfalls keine abweichenden Methoden) es ist sofort klar, welche Methoden für die Felder zur Verfügung stehen werden.

go Die Vorteile auf und auf ..

In meinem Kopf geht es nicht um Code zu reduzieren, sondern um klar zu kommunizieren, was Sie erreichen wollen, anstatt es von Javadoc oder Implementierungen herauszufinden. Der reduzierte Code nur macht es einfacher, all divergent-Methode Implementierungen zu erkennen.

Lombok ist groß, aber ...

Lombok bricht die Regeln der Anmerkungsverarbeitung, dass es keine neue Quelldateien erzeugt. Dies bedeutet, es kann nicht mit einem anderen Anmerkung Prozessoren verwendet werden, wenn sie die Getter / Setter oder was auch immer existieren erwartet.

Annotation Verarbeitung läuft in einer Reihe von Runden. In jeder Runde bekommt jeder eine Umdrehung auszuführen. Wenn neue Java-Dateien gefunden werden, nachdem die Runde beendet ist, beginnt eine neue Runde. Auf diese Weise wird die Reihenfolge der Anmerkung Prozessoren keine Rolle, ob sie nur neue Dateien erzeugen. Da lombok erzeugt keine neuen Dateien, werden keine neuen Runden gestartet, um einige AP, die auf lombok Code verlässt sich nicht wie erwartet ausgeführt. Das war eine große Quelle von Schmerz für mich, während mapstruct verwenden und delombok-ing ist keine sinnvolle Option, da sie Ihre Zeilennummern in Protokollen zerstört.

ich gehackt schließlich ein Build-Skript zu arbeiten sowohl mit lombok und mapstruct. Aber ich will lombok fallen durch, wie Hacky es ist - in diesem Projekt zumindest. Ich benutze die ganze Zeit in anderen Sachen LOMBOK.

Es gibt langfristige Wartung als auch Risiken. Erstens, ich würde empfehlen, lesen, wie Lombok tatsächlich funktioniert, z.B. einige Antworten aus seinen Entwicklern href="https://stackoverflow.com/questions/6107197/how-does-lombok-work">.

Die offizielle Website enthält auch eine Liste der Nachteile , einschließlich dieses Zitat aus Reinier Zwitserloot:

Es ist ein Gesamt Hack. Die Verwendung von nicht-öffentlichen API. Anmaßend Gießen (zu wissen,   dass eine Anmerkung Prozessor in Javac ausgeführt wird eine Instanz erhalten   JavacAnnotationProcessor, das ist die interne Implementierung   AnnotationProcessor (eine Schnittstelle), die so ein Paar haben geschieht   von zusätzlichen Methoden, die verwendet werden, um den Live-AST zu bekommen).

auf Eclipse, dann ist es wohl schlimmer (und noch robustes) - ein Java-Agent   verwendet wird Code in der Eklipse Grammatik- und Parserklasse einzuspritzen,   Das ist natürlich völlig nicht-öffentliche API und völlig tabu.

Wenn Sie das tun können, was lombok tut mit Standard-API, ich getan hätte,   es auf diese Weise, aber man kann es nicht. Doch für was ihren Wert, entwickelte ich die   Eclipse-Plugin für Eclipse v3.5 läuft auf Java 1.6, und ohne   Vornehmen von Änderungen auf Eclipse v3.4 läuft auf Java arbeiten 1.5 als   na ja, so ist es nicht völlig instabil.

Als Zusammenfassung, während Lombok können Sie einige Entwicklungszeit sparen, wenn es einen nicht-rückwärtskompatibel ist javac Update (zB eine Verwundbarkeit Mitigation) Lombok könnte bekommen Sie mit einer alten Version von Java stecken, während die Entwickler zu aktualisieren Gerangel um ihre Nutzung dieser internen APIs. Ob dies ein ernsthaftes Risiko hängt offensichtlich von dem Projekt.

Ich lese einige Meinungen über die Lombok und tatsächlich in einigen Projekten verwende ich es.

Nun, in dem ersten Kontakt mit Lombok Ich hatte einen schlechten Eindruck. Nach einigen Wochen begann ich es zu mögen. Aber nach einigen Monaten ich heraus viele kleine Probleme heraus es zu benutzen. Also, mein letzter Eindruck über Lombok ist nicht so positiv.

Meine Gründe auf diese Weise zu denken:

IDE-Plugin Abhängigkeit . Die IDE-Unterstützung für Lombok ist durch Plugins. Auch gut ins meist Teil der Zeit arbeitet, sind Sie immer eine Geisel aus diesem Plug-in in den zukünftigen Versionen der IDEs und sogar beibehalten werden die Sprachversion (Java 10+ wird die Entwicklung der Sprache beschleunigen). Per Beispiel habe ich von IntelliJ IDE 2017,3 bis 2018,1 zu aktualisieren versucht, und ich konnte nicht tun, weil es ein Problem auf dem tatsächlichen lombok Plugin-Version ist, und ich muss das Plugin aktualisiert werden, warten ... Dies ist auch ein Problem, wenn Sie möchte eine weitere alternative IDE verwenden, die keine Lombok Plugin-Unterstützung haben.
'Suchen Verbräuche' Problem. . Mit Lombok Sie nicht sehen die generierten Getter, Setter, Konstrukteur, Erbauer Methoden und etc. Also, wenn Sie, was diese Methoden, um herauszufinden, planen in Ihrem Projekt von Ihrem IDE verwendet wird, können Sie dies nicht nur Suche nach der Klasse, die diese versteckten Methoden besitzt.
So einfach, dass die Entwickler kümmern sich nicht die Verkapselung zu brechen . Ich weiß, dass es nicht wirklich ein Problem von Lombok ist. Aber ich sah eine größere Neigung zum Entwickler nicht mehr kontrollieren, welche Methoden Bedürfnisse sichtbar oder nicht sein. Also, sie oft sind nur Kopieren und Einfügen @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor Anmerkungen, ohne zu denken, welche Methoden die Klasse wirklich brauchen, um aus.
Builder Obssession ©. Ich erfand diesen Namen (aussteigen, Martin Fowler). Witze abgesehen, ist ein Builder so einfach, dass selbst zu erstellen, wenn eine Klasse nur zwei Parameter die Entwickler lieber Verwendung @Builder statt Konstruktor oder einem statischen Konstruktor haben. Manchmal versuchen sie sogar einen Builder in der lombok Builder, die Schaffung seltsame Situationen wie MyClass.builder().name("Name").build().create() zu erstellen.
Schranken, wenn Refactoring . Wenn Sie verwenden, pro Beispiel ein @AllArgsConstructor und Bedarf einen weiteren Parameter an dem Konstruktor hinzufügen, kann das IDE nicht helfen, diese zusätzlichen Parameter in allen Orten hinzufügen (meist, Tests), die die Klasse instanziieren.
Mix Lombok mit konkreten Methoden . Sie können Lombok nicht in allen Szenarien verwenden, um einen Getter / Setter / etc zu erstellen. Also, werden Sie diese beiden Ansätze gemischt in Ihrem Code sehen. Man gewöhnt sich an diese nach einiger Zeit verwendet, fühlt sich aber wie ein Hack auf die Sprache.

Wie andere Antwort gesagt, wenn Sie wütend über die Java Ausführlichkeit und nutzen Lombok damit umgehen, versuchen Kotlin.

Ich weiß, ich bin spät dran, aber ich kann der Versuchung nicht widerstehen: für jedermann mögen Lombok auch einen Blick auf Scala haben sollte. Viele gute Ideen, dass Sie in Lombok finden sind Teil der Scala Sprache.

Auf Ihrer Frage: Es ist auf jeden Fall einfacher Ihre Entwickler zu bekommen versuchen, Lombok als Scala. Probieren Sie es aus und wenn sie, wie es versucht Scala.

Wie Haftungsausschluss: Ich habe wie Java, zu

Ich habe ein Jahr lang Lombok in fast alle meine Projekte verwendet, aber leider ist es entfernt. Am Anfang ist es eine sehr saubere Art und Weise der Entwicklung, sondern die Entwicklungsumgebung für neue Teammitglieder Einrichtung ist nicht sehr einfach und unkompliziert. Wenn es ein Kopfschmerz wurde ich einfach entfernt. Aber es ist eine gute Arbeit und braucht etwas mehr Einfachheit der Einrichtung.

Als ich das Projekt auf meinem Team zeigte, war die Begeisterung hoch, so dass ich glaube, Sie keine Angst vor dem Team Antwort sein sollten.

Was ROI, es ist ein zu integrieren Snap und erfordert in seiner Grundform keine Codeänderung. (Nur eine einzige Anmerkung zu Ihrer Klasse hinzufügen)
Und schließlich, wenn Sie Ihre Meinung ändern, können Sie die unlombok laufen, oder lassen Sie Ihre IDE erstellen, um diese Setter, Getter und ctors, (was ich denke, niemand fragen, wenn sie sehen, wie klar deine pojo wird)

Will @ToString die Nutzung lombok aber bald konfrontiert Zufall Kompilierung Fehler auf Projekt in IntelliJ IDEA wieder aufzubauen. Hat die Kompilierung mehrmals zu treffen, bevor inkrementale Kompilierung mit Erfolg abschließen kann.

versucht, beide lombok 1.12.2 und 0.9.3 mit IntelliJ IDEA 12.1.6 und 13.0 ohne lombok Plugin unter jdk 1.6.0_39 und 1.6.0_45.

Muß manuell kopieren generierten Methoden aus delomboked Quelle und setzt lombok in den Warteschleife, bis bessere Zeiten.

Aktualisieren

Das Problem tritt nur bei parallel Kompilierung aktiviert.

Filed ein Problem aufgetreten: https://github.com/rzwitserloot/lombok/issues/648

Aktualisieren

mplushnikov am 30. Januar 2016 kommentiert:

Neuere Version von IntelliJ   mehr nicht solche Probleme haben. Ich denke, es kann hier geschlossen werden.

Aktualisieren

Ich würde sehr zu Wechsel von Java + Lombok empfehlen Kotlin wenn möglich. Wie es von Grund auf alle Java-Probleme gelöst hat, dass Lombok versucht, um zu arbeiten.

Mein Nehmen auf Lombok ist, dass es nur Verknüpfungen zum Schreiben bolilerplate Java-Code zur Verfügung stellt.
Wenn es Verknüpfungen zu verwenden zum Schreiben bolilerplate Java-Code kommt, würde ich auf solchen Merkmalen von IDE bereitgestellt verlassen - wie in Eclipse, können wir zum Menü gehen Source> Gene Getter und Setter für Getter und Setter zu erzeugen
. Ich würde nicht für diesen auf einer Bibliothek wie Lombok verlassen:

Sie verpestet Ihren Code mit einer indirection Schicht alternativer Syntax (Lese @Getter, @Setter usw. Anmerkungen). Anstatt eine alternative Syntax für Java zu lernen, würde ich wechseln zu einer anderen Sprache, die nativen Lombok bietet ähnliche Syntax.
Lombok erfordert die Verwendung eines Lombok IDE mit Code zur Arbeit unterstützt. Diese Abhängigkeit führt ein erhebliches Risiko für jedes nicht-triviales Projekt. Hat das Open-Source-Projekt Lombok genügend Ressourcen für verschiedene Versionen von einer breiten Palette von Java-IDE zur Verfügung zu halte Unterstützung?
Ist das Open-Source-Projekt Lombok genügend Ressourcen zu halte Unterstützung für neuere Versionen von Java, die in Zukunft kommen werden?
ich auch nervös Gefühl, dass Lombok Kompatibilitätsprobleme einführen kann mit weit verbreiteten Frameworks / Bibliotheken (wie Spring, Hibernate, Jackson, JUnit, Mockito) dass die Arbeit mit Ihrem Byte-Code zur Laufzeit.

Alles in allem würde ich nicht zu „würzen“ lieber meine Java mit Lombok.

Ich habe ein Problem mit begegnet Lombok und Jackson CSV , wenn ich marshalized mein Objekt (Java Bean) in eine CSV-Datei, wo dupliziert Spalten, dann entfernte ich Lombok @ data-Annotation und marshalizing hat gut funktioniert.

ich es nicht empfehlen. Früher habe ich es zu benutzen, aber dann, wenn ich mit NetBeans arbeiten 7.4 war es meine Codes durcheinander. Ich habe in allen Dateien in meinen Projekten entfernen lombok. Es gibt delombok, aber wie kann ich sicher sein, wäre es nicht meine Codes schrauben. Ich muss verbringt Tage nur zu entfernen lombok und zurück zum normalen Java Stile. Ich habe gerade zu scharf ...

Ich habe noch nicht mit Lombok versucht - es ist / war die nächste auf meiner Liste, aber es klingt, als ob Java 8 für sie erhebliche Probleme verursacht hat, und Sanierungsarbeiten noch im Gang waren als vor einer Woche. Meine Quelle für das heißt https://code.google.com/p/ projectlombok / Themen / detail? id = 451 .

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow