Ist es sicher, Project Lombok zu verwenden? [geschlossen]

Falls Sie nicht wissen, dass Project Lombok bei einigen Problemen von Java hilft, z. B. beim Generieren von Gettern und Setzern mit Anmerkungen und sogar bei der einfachen JavaBean-ähnlichen Generierung mit @Data . Es könnte mir wirklich helfen, insbesondere in 50 verschiedenen Ereignisobjekten, in denen Sie bis zu 7 verschiedene Felder haben, die mit Gettern konstruiert und versteckt werden müssen. Ich könnte damit fast tausend Codezeilen entfernen.

Ich mache mir jedoch Sorgen, dass es auf lange Sicht eine bedauerliche Entscheidung sein wird. Flamewars werden im ##Java FreenodeKanal ausbrechen , wenn ich es erwähne. Wenn Code-Snippets bereitgestellt werden, werden mögliche Helfer verwirrt, die Leute werden sich über fehlendes JavaDoc beschweren und zukünftige Commiter werden möglicherweise sowieso alles entfernen. Ich würde das Positive wirklich genießen, aber ich mache mir Sorgen um das Negative.

Also: Ist es sicher, Lombok für jedes kleine oder große Projekt zu verwenden? Sind die positiven Effekte die negativen wert?

Es hört sich so an, als hätten Sie bereits entschieden, dass Project Lombok Ihnen erhebliche technische Vorteile für Ihr vorgeschlagenes neues Projekt bietet. (Um von Anfang an klar zu sein, habe ich auf die eine oder andere Weise keine besonderen Ansichten über Project Lombok.)

Bevor Sie Project Lombok (oder eine andere bahnbrechende Technologie) in einem Projekt (Open Source oder auf andere Weise) verwenden, müssen Sie sicherstellen, dass die Projektbeteiligten dem zustimmen. Dies schließt die Entwickler und alle wichtigen Benutzer (z. B. formelle oder informelle Sponsoren) ein.

Sie erwähnen diese potenziellen Probleme:

Flamewars werden im ## Java Freenode-Kanal ausbrechen, wenn ich es erwähne,

Einfach. Ignoriere / nimm nicht an den Flammenkriegen teil oder erwähne einfach nicht Lombok.

Das Bereitstellen von Codefragmenten verwirrt mögliche Helfer.

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

Leute werden sich über fehlendes JavaDoc beschweren,

Das ist ihr Problem. Niemand, der bei klarem Verstand ist, versucht, die Quellcode- / Dokumentationsregeln seines Unternehmens strikt auf Open Source-Software von Drittanbietern anzuwenden. Dem Projektteam sollte es freigestellt sein, Projektquellcode- / Dokumentationsstandards festzulegen, die für die verwendete Technologie geeignet sind.

( FOLLOWUP - Die Lombok-Entwickler erkennen, dass es kein Problem ist, keine Javadoc-Kommentare für synthetisierte Getter- und Setter-Methoden zu generieren. Wenn dies ein großes Problem für Ihre Projekte darstellt, besteht eine Alternative darin, einen Lombok-Patch zu erstellen und einzureichen, um dies zu beheben. )

und zukünftige Committer könnten sowieso alles entfernen.

Das geht nicht! Wenn die vereinbarte Projektstrategie darin besteht, Lombok zu verwenden, sollten Committers, die den Code unentgeltlich de-lombokieren, bestraft werden und gegebenenfalls ihre Commit-Rechte entziehen.

Dies setzt natürlich voraus, dass Sie ein Buy-In von den Stakeholdern erhalten haben ... einschließlich der Entwickler. Und es setzt voraus, dass Sie bereit sind, Ihre Sache zu argumentieren und angemessen mit den unvermeidlichen Gegenstimmen umzugehen.

Ich habe gerade angefangen, Lombok zu benutzen. Bisher gefällt es mir, aber ein Nachteil, den ich nicht erwähnt habe, war die Umgestaltung der Unterstützung.

Wenn Sie eine Klasse mit Anmerkungen versehen haben @Data, werden die Getter und Setter basierend auf den Feldnamen für Sie generiert. Wenn Sie einen dieser Getter in einer anderen Klasse verwenden und dann entscheiden, dass das Feld einen schlechten Namen hat, werden die Verwendungen dieser Getter und Setter nicht gefunden und der alte Name durch den neuen Namen ersetzt.

Ich würde mir vorstellen, dass dies über ein IDE-Plug-In und nicht über Lombok erfolgen müsste.

UPDATE (22. Januar 13)
Nachdem ich Lombok 3 Monate lang verwendet habe, empfehle ich es für die meisten Projekte. Ich habe jedoch einen anderen Nachteil gefunden, der dem oben aufgeführten ähnlich ist.

Wenn Sie eine Klasse haben, sagen wir MyCompoundObject.java, die 2 Mitglieder hat, die beide mit Anmerkungen versehen @Delegatesind, myWidgetsund myGadgetswenn Sie myCompoundObject.getThingies()von einer anderen Klasse aus anrufen , ist es unmöglich zu wissen, ob sie an die delegiert wird Widgetoder Gadgetweil Sie nicht mehr innerhalb der IDE zur Quelle springen können.

Die Verwendung der Eclipse "Delegate-Methoden generieren ..." bietet Ihnen die gleiche Funktionalität, ist genauso schnell und ermöglicht das Springen von Quellen. Der Nachteil ist, dass es Ihre Quelle mit Boilerplate-Code überfüllt, der den Fokus von den wichtigen Dingen ablenkt.

UPDATE 2 (26. Februar 13)
Nach 5 Monaten verwenden wir immer noch Lombok, aber ich habe einige andere Probleme. Das Fehlen eines deklarierten Getters & Setters kann manchmal ärgerlich werden, wenn Sie versuchen, sich mit neuem Code vertraut zu machen.

Wenn ich zum Beispiel eine Methode mit dem Namen getDynamicCols()sehe, aber nicht weiß, worum es geht, muss ich einige zusätzliche Hürden überwinden, um den Zweck dieser Methode zu bestimmen. Einige der Hürden sind Lombok, andere das Fehlen eines Lombok Smart Plugins. Zu den Hürden gehören:

• Mangel an JavaDocs. Wenn ich das Feld javadociere, würde ich hoffen, dass der Getter und der Setter dieses Javadoc durch den Lombok-Kompilierungsschritt erben würden.
• Zur Methodendefinition springen springt mich zur Klasse, aber nicht zu der Eigenschaft, die den Getter generiert hat. Dies ist ein Plugin-Problem.
• Offensichtlich können Sie in einem Getter / Setter keinen Haltepunkt setzen, es sei denn, Sie generieren oder codieren die Methode.
• HINWEIS: Diese Referenzsuche ist kein Problem, wie ich es zuerst dachte. Sie müssen jedoch eine Perspektive verwenden, die die Gliederungsansicht aktiviert. Für die meisten Entwickler kein Problem. Mein Problem war, dass ich Mylyn verwende, das meine OutlineAnsicht filtert , sodass ich die Methoden nicht gesehen habe. Suche nach fehlenden Referenzen. Wenn ich sehen möchte, wer anruft getDynamicCols(args...), muss ich den Setter generieren oder codieren, um nach Referenzen suchen zu können.

UPDATE 3 (7. März 13)
Ich denke, ich lerne, die verschiedenen Methoden in Eclipse anzuwenden. Sie können einen bedingten Haltepunkt (BP) für eine von Lombok generierte Methode festlegen. In der OutlineAnsicht können Sie mit der rechten Maustaste auf die Methode klicken, um Toggle Method Breakpoint. Wenn Sie dann auf den BP klicken , können Sie in der Debugging- VariablesAnsicht sehen, wie die generierte Methode die Parameter benannt hat (normalerweise derselbe wie der Feldname), und schließlich in der BreakpointsAnsicht mit der rechten Maustaste auf den BP klicken und Breakpoint Properties...eine Bedingung hinzufügen. Nett.

UPDATE 4 (16. August 13)
Netbeans mag es nicht, wenn Sie Ihre Lombok-Abhängigkeiten in Ihrem Maven Pom aktualisieren. Das Projekt wird immer noch kompiliert, aber Dateien werden wegen Kompilierungsfehlern markiert, da die von Lombok erstellten Methoden nicht angezeigt werden. Durch Löschen des Netbeans-Cache wird das Problem behoben. Ich bin mir nicht sicher, ob es eine Option "Projekt bereinigen" wie in Eclipse gibt. Kleines Problem, wollte es aber bekannt machen.

UPDATE 5 (17. Januar 14)
Lombok spielt nicht immer gut mit Groovy oder zumindest dem groovy-eclipse-compiler. Möglicherweise müssen Sie Ihre Version des Compilers herunterstufen. Maven Groovy und Java + Lombok

UPDATE 6 (26. Juni 14)
Ein Wort der Warnung. Lombok macht leicht süchtig und wenn Sie an einem Projekt arbeiten, bei dem Sie es aus irgendeinem Grund nicht verwenden können, wird es Sie nerven. Sie sind vielleicht besser dran, wenn Sie es überhaupt nicht benutzen.

UPDATE 7 (23. Juli 14)
Dies ist ein interessantes Update, da es sich direkt mit der Sicherheit der Übernahme von Lombok befasst, nach der das OP gefragt hat.

Ab Version 1.14 wurde die @DelegateAnmerkung auf einen experimentellen Status herabgestuft . Die Details sind auf ihrer Website dokumentiert ( Lombok Delegate Docs ).

Die Sache ist, wenn Sie diese Funktion verwenden, sind Ihre Backout-Optionen begrenzt. Ich sehe die Optionen als:

• Entfernen Sie @DelegateAnmerkungen manuell und generieren / handcodieren Sie den Delegatencode. Dies ist etwas schwieriger, wenn Sie Attribute in der Anmerkung verwenden.
• Löschen Sie die Dateien mit der @DelegateAnmerkung und fügen Sie sie möglicherweise wieder in die gewünschten Anmerkungen ein.
• Aktualisieren Sie niemals Lombok oder warten Sie eine Gabel (oder leben Sie mit Erfahrungsfunktionen).
• Delombok dein gesamtes Projekt und benutze Lombok nicht mehr.

Soweit ich das beurteilen kann, hat Delombok keine Option, eine Teilmenge von Anmerkungen zu entfernen . Zumindest für den Kontext einer einzelnen Datei ist alles oder nichts. Ich habe ein Ticket geöffnet , um diese Funktion mit Delombok-Flaggen anzufordern, aber ich würde das in naher Zukunft nicht erwarten.

UPDATE 8 (20. Oktober 14)
Wenn es eine Option für Sie ist, bietet Groovy die meisten Vorteile von Lombok sowie eine Bootsladung anderer Funktionen, einschließlich @Delegate . Wenn Sie der Meinung sind, dass es Ihnen schwer fällt, die Idee an die Mächte zu verkaufen, werfen Sie einen Blick auf die @CompileStaticoder die @TypeCheckedAnmerkung, um zu sehen, ob dies Ihrer Sache helfen kann. Tatsächlich lag der Schwerpunkt der Version von Groovy 2.0 auf der statischen Sicherheit .

UPDATE 9 (1. September 15)
Lombok wird immer noch aktiv gewartet und verbessert , was ein gutes Zeichen für das Sicherheitsniveau der Adoption ist. Die @ Builder- Anmerkungen sind eine meiner neuen Lieblingsfunktionen.

UPDATE 10 (17. November 15)
Dies scheint nicht direkt mit der Frage des OP verbunden zu sein, ist aber eine Weitergabe wert. Wenn Sie nach Tools suchen, mit denen Sie die Menge des von Ihnen geschriebenen Boilerplate-Codes reduzieren können, können Sie auch Google Auto - insbesondere AutoValue - ausprobieren . Wenn Sie sich ihr Dia-Deck ansehen , finden Sie in der Liste Lombok eine mögliche Lösung für das Problem, das sie zu lösen versuchen. Die Nachteile, die sie für Lombok auflisten, sind:

• Der eingefügte Code ist unsichtbar (Sie können die generierten Methoden nicht "sehen") [ed note - eigentlich können Sie das, aber es ist nur ein Dekompiler erforderlich]
• Die Compiler-Hacks sind nicht standardisiert und zerbrechlich
• "Aus unserer Sicht ist Ihr Code nicht mehr wirklich Java"

Ich bin mir nicht sicher, wie sehr ich ihrer Bewertung zustimme. Und angesichts der Nachteile von AutoValue, die in den Folien dokumentiert sind, bleibe ich bei Lombok (wenn Groovy keine Option ist).

UPDATE 11 (8. Februar 16)
Ich habe herausgefunden, dass Spring Roo einige ähnliche Anmerkungen hat . Ich war ein wenig überrascht, als ich herausfand, dass Roo immer noch eine Sache ist und die Dokumentation für die Anmerkungen etwas rau ist. Das Entfernen sieht auch nicht so einfach aus wie De-Lombok. Lombok scheint die sicherere Wahl zu sein.

UPDATE 12 (17. Februar 16)
Während ich versuchte, Rechtfertigungen dafür zu finden, warum es sicher ist, Lombok für das Projekt, an dem ich gerade arbeite, einzubringen, fand ich ein Stück Gold, das mit v1.14- The Configuration System ! Dies bedeutet, dass Sie ein Projekt so konfigurieren können, dass bestimmte Funktionen, die Ihr Team als unsicher oder unerwünscht erachtet, deaktiviert werden. Besser noch, es kann auch eine verzeichnisspezifische Konfiguration mit unterschiedlichen Einstellungen erstellen. Das ist fantastisch.

UPDATE 13 (4. Oktober 16)
Wenn Ihnen so etwas wichtig ist, war es für Oliver Gierke sicher, Lombok zu Spring Data Rest hinzuzufügen .

UPDATE 14 (26. September 17)
Wie von @gavenkoa in den Kommentaren zur OP-Frage hervorgehoben, ist die JDK9-Compiler-Unterstützung noch nicht verfügbar ( Problem Nr. 985). Es klingt auch so, als ob es für das Lombok-Team keine einfache Lösung sein wird, sich fortzubewegen.

UPDATE 15 (26. März 18)
Das Lombok-Änderungsprotokoll zeigt ab Version 1.16.20 an, dass das Kompilieren von Lombok auf JDK1.9 jetzt möglich ist , obwohl # 985 noch offen ist.

Änderungen an JDK9 erforderten jedoch einige wichtige Änderungen. Alle sind auf Änderungen der Konfigurationsstandards isoliert. Es ist ein wenig besorgniserregend, dass sie grundlegende Änderungen eingeführt haben, aber die Version hat nur die "Inkrementelle" Versionsnummer (von v1.16.18 auf v1.16.20) erhöht. Da es in diesem Beitrag um die Sicherheit ging yarn/npm, könnten Sie ein unhöfliches Erwachen erleben, wenn Sie ein ähnliches Build-System hätten, das automatisch auf die neueste inkrementelle Version aktualisiert wurde.

UPDATE 16 (9. Januar 19)

Es scheint, dass die JDK9-Probleme behoben wurden und Lombok mit JDK10 und sogar JDK11 arbeitet, soweit ich das beurteilen kann.

Eine Sache, die mir aus Sicherheitsgründen aufgefallen ist, ist die Tatsache, dass im Änderungsprotokoll von Version 1.18.2 auf Version 1.18.4 zwei Elemente als BREAKING CHANGE! Aufgeführt werden . Ich bin mir nicht sicher, wie eine bahnbrechende Änderung in einem semver "Patch" -Update geschieht. Kann ein Problem sein, wenn Sie ein Tool verwenden, das Patch-Versionen automatisch aktualisiert.

Gehen Sie voran und verwenden Sie Lombok. Sie können Ihren Code bei Bedarf anschließend "delombok" http://projectlombok.org/features/delombok.html

Persönlich (und daher subjektiv) habe ich festgestellt, dass die Verwendung von Lombok meinen Code im Vergleich zu IDE / eigenen Implementierungen komplizierter Methoden wie Hashcode & Equals ausdrucksvoller macht, was ich erreichen möchte.

Beim Benutzen

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

Es ist viel einfacher, Equals & HashCode konsistent zu halten und zu verfolgen, welche Felder ausgewertet werden, als jede IDE / eigene Implementierung. Dies gilt insbesondere dann, wenn Sie noch regelmäßig Felder hinzufügen / entfernen.

Gleiches gilt für die @ToStringAnnotation und ihre Parameter, die das gewünschte Verhalten in Bezug auf eingeschlossene / ausgeschlossene Felder, die Verwendung von Gettern oder den Feldzugriff und ob ob aufgerufen werden soll oder nicht, klar kommunizieren super.toString().

Und wieder wird durch Annotieren einer gesamten Klasse mit @Getteroder @Setter(AccessLevel.NONE)(und optional durch Überschreiben unterschiedlicher Methoden) sofort klar, welche Methoden für die Felder verfügbar sind.

Die Vorteile gehen weiter und weiter ..

In meinen Augen geht es nicht darum, Code zu reduzieren, sondern klar zu kommunizieren, was Sie erreichen möchten, anstatt es aus Javadoc oder Implementierungen herauszufinden. Der reduzierte Code erleichtert lediglich das Erkennen von Implementierungen mit unterschiedlichen Methoden.

Lombok ist großartig, aber ...

Lombok verstößt gegen die Regeln der Annotationsverarbeitung, da keine neuen Quelldateien generiert werden. Dies bedeutet, dass es nicht mit anderen Annotationsprozessoren verwendet werden kann, wenn sie erwarten, dass die Getter / Setter oder was auch immer existieren.

Die Verarbeitung von Anmerkungen erfolgt in mehreren Runden. In jeder Runde bekommt jeder eine Runde zum Laufen. Wenn nach Abschluss der Runde neue Java-Dateien gefunden werden, beginnt eine weitere Runde. Auf diese Weise spielt die Reihenfolge der Anmerkungsprozessoren keine Rolle, wenn sie nur neue Dateien generieren. Da lombok keine neuen Dateien generiert, werden keine neuen Runden gestartet, sodass einige APs, die auf Lombok-Code basieren, nicht wie erwartet ausgeführt werden. Dies war eine große Schmerzquelle für mich bei der Verwendung von Mapstruct, und Delomboking ist keine nützliche Option, da es Ihre Zeilennummern in Protokollen zerstört.

Ich habe schließlich ein Build-Skript gehackt, um sowohl mit Lombok als auch mit Mapstruct zu arbeiten. Aber ich möchte Lombok fallen lassen, weil es so hackig ist - zumindest in diesem Projekt. Ich benutze Lombok die ganze Zeit in anderen Sachen.

Ich habe einige Meinungen über den Lombok gelesen und benutze ihn tatsächlich in einigen Projekten.

Nun, beim ersten Kontakt mit Lombok hatte ich einen schlechten Eindruck. Nach einigen Wochen fing ich an, es zu mögen. Aber nach einigen Monaten habe ich viele kleine Probleme damit. Mein letzter Eindruck von Lombok ist also nicht so positiv.

Meine Gründe, so zu denken:

• IDE-Plugin-Abhängigkeit . Die IDE-Unterstützung für Lombok erfolgt über Plugins. Selbst wenn Sie die meiste Zeit gut arbeiten, sind Sie immer eine Geisel dieser Plugins, die in zukünftigen Versionen der IDEs und sogar der Sprachversion beibehalten werden (Java 10+ beschleunigt die Entwicklung der Sprache). Ich habe zum Beispiel versucht, ein Update von Intellij IDEA 2017.3 auf 2018.1 durchzuführen, und das konnte ich nicht, da es ein Problem mit der aktuellen Version des Lombok-Plugins gab und ich warten musste, bis das Plugin aktualisiert wurde ... Dies ist auch ein Problem, wenn Sie Ich möchte eine alternative IDE verwenden, die keine Unterstützung für Lombok-Plugins bietet.
• Problem "Verwendungen finden". . Mit Lombok werden die generierten Getter-, Setter-, Konstruktor-, Builder-Methoden usw. nicht angezeigt. Wenn Sie also herausfinden möchten, wo diese Methoden von Ihrer IDE in Ihrem Projekt verwendet werden, können Sie dies nicht nur suchen für die Klasse, die diese versteckten Methoden besitzt.
• So einfach, dass es den Entwicklern egal ist, die Kapselung zu brechen . Ich weiß, dass es kein wirkliches Problem von Lombok ist. Aber ich sah eine größere Tendenz der Entwickler, nicht mehr zu kontrollieren, welche Methoden sichtbar sein müssen oder nicht. Oft kopieren und fügen sie nur @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorAnnotationsblöcke ein, ohne zu überlegen, welche Methoden die Klasse wirklich verfügbar machen muss.
• Builder Obssession ©. Ich habe diesen Namen erfunden (steigen Sie aus, Martin Fowler). Abgesehen von Witzen ist ein Builder so einfach zu erstellen, dass die Entwickler selbst dann, wenn eine Klasse nur zwei Parameter hat, lieber einen @BuilderKonstruktor als eine statische Konstruktormethode verwenden. Manchmal versuchen sie sogar, einen Builder im lombok Builder zu erstellen, was zu seltsamen Situationen führt MyClass.builder().name("Name").build().create().
• Hindernisse beim Refactoring . Wenn Sie beispielsweise a verwenden @AllArgsConstructorund dem Konstruktor einen weiteren Parameter hinzufügen müssen, kann die IDE Ihnen nicht helfen, diesen zusätzlichen Parameter an allen Stellen (meistens Tests) hinzuzufügen, die die Klasse instanziieren.
• Mischen von Lombok mit konkreten Methoden . Sie können Lombok nicht in allen Szenarien verwenden, um einen Getter / Setter / etc. Zu erstellen. Sie werden also sehen, dass diese beiden Ansätze in Ihrem Code gemischt sind. Man gewöhnt sich nach einiger Zeit daran, fühlt sich aber wie ein Hack auf die Sprache.

Wie eine andere Antwort sagte, wenn Sie über die Java-Ausführlichkeit verärgert sind und Lombok verwenden, um damit umzugehen, versuchen Sie es mit Kotlin.

Es bestehen auch langfristige Wartungsrisiken. Zunächst würde ich empfehlen, darüber zu lesen, wie Lombok tatsächlich funktioniert, z. B. einige Antworten der Entwickler hier .

Die offizielle Seite enthält auch eine Liste der Nachteile , einschließlich dieses Zitats von Reinier Zwitserloot:

Es ist ein totaler Hack. Nicht öffentliche API verwenden. Anmaßendes Casting (in dem Wissen, dass ein in javac ausgeführter Annotationsprozessor eine Instanz von JavacAnnotationProcessor erhält, der internen Implementierung von AnnotationProcessor (einer Schnittstelle), die zufällig über einige zusätzliche Methoden verfügt, die zum Abrufen des Live-AST verwendet werden) .

Bei Eclipse ist es wohl schlimmer (und dennoch robuster) - ein Java-Agent wird verwendet, um Code in die Eclipse-Grammatik- und Parser-Klasse einzufügen, die natürlich eine völlig nicht öffentliche API ist und völlig verboten ist.

Wenn Sie das tun könnten, was Lombok mit der Standard-API macht, hätte ich es so gemacht, aber Sie können nicht. Trotzdem habe ich das Eclipse-Plugin für Eclipse v3.5 unter Java 1.6 entwickelt. Ohne Änderungen funktionierte es auch unter Eclipse v3.4 unter Java 1.5, sodass es nicht vollständig zerbrechlich ist.

Zusammenfassend lässt sich sagen, dass Lombok Ihnen möglicherweise Entwicklungszeit spart, wenn es jedoch ein nicht abwärtskompatibles Javac-Update gibt (z. B. eine Schwachstellenminderung). Lombok kann dazu führen, dass Sie mit einer alten Java-Version nicht weiterkommen, während die Entwickler sich bemühen, deren Verwendung zu aktualisieren interne APIs. Ob dies ein ernstes Risiko darstellt, hängt offensichtlich vom Projekt ab.

Ich weiß, dass ich zu spät komme, aber ich kann der Versuchung nicht widerstehen: Wer Lombok mag, sollte sich auch Scala ansehen. Viele gute Ideen, die Sie in Lombok finden, sind Teil der Scala-Sprache.

Zu Ihrer Frage: Es ist definitiv einfacher, Ihre Entwickler dazu zu bringen, Lombok auszuprobieren als Scala. Probieren Sie es aus und wenn es ihnen gefällt, versuchen Sie es mit Scala.

Nur als Haftungsausschluss: Ich mag auch Java!

Ich habe Lombok ein Jahr lang in fast allen meinen Projekten verwendet, es aber leider entfernt. Am Anfang war es eine sehr saubere Art der Entwicklung, aber das Einrichten der Entwicklungsumgebung für neue Teammitglieder ist nicht sehr einfach und unkompliziert. Als es Kopfschmerzen bekam, habe ich es einfach entfernt. Aber es ist eine gute Arbeit und erfordert etwas mehr Einfachheit beim Einrichten.

Als ich meinem Team das Projekt zeigte, war die Begeisterung hoch, daher sollten Sie keine Angst vor Teamreaktionen haben.

• In Bezug auf den ROI ist die Integration ein Kinderspiel und erfordert keine Codeänderung in der Grundform. (Hinzufügen einer einzelnen Anmerkung zu Ihrer Klasse)

• Und zuletzt, wenn Sie Ihre Meinung ändern, können Sie den Unlombok ausführen oder Ihre IDE diese Setter, Getter und Ctors erstellen lassen (was meiner Meinung nach niemand verlangen wird, sobald er sieht, wie klar Ihr Pojo wird).

Mein Standpunkt zu Lombok ist, dass es lediglich Verknüpfungen zum Schreiben von Bolilerplate-Java-Code bietet.
Wenn es darum geht, Verknüpfungen zum Schreiben von Bolilerplate-Java-Code zu verwenden, würde ich mich auf solche Funktionen verlassen, die von IDE bereitgestellt werden. Wie in Eclipse können wir zum Generieren von Gettern und Setzern das Menü Quelle> Getter und Setter generieren aufrufen.
Ich würde mich dafür nicht auf eine Bibliothek wie Lombok verlassen:

1. Es verpestet Ihren Code mit einer indirection Schicht alternativer Syntax (lesen @Getter, @Setterusw. Anmerkungen). Anstatt eine alternative Syntax für Java zu lernen, würde ich zu einer anderen Sprache wechseln, die nativ Lombok-ähnliche Syntax bietet.
2. Lombok erfordert die Verwendung einer von Lombok unterstützten IDE, um mit Ihrem Code arbeiten zu können. Diese Abhängigkeit birgt ein erhebliches Risiko für jedes nicht triviale Projekt. Verfügt das Open-Source-Lombok-Projekt über genügend Ressourcen, um weiterhin Unterstützung für verschiedene Versionen einer Vielzahl von verfügbaren Java-IDEs bereitzustellen?
3. Verfügt das Open-Source-Lombok-Projekt über genügend Ressourcen, um weiterhin Unterstützung für neuere Java-Versionen bereitzustellen, die in Zukunft verfügbar sein werden?
4. Ich bin auch nervös, dass Lombok Kompatibilitätsprobleme mit weit verbreiteten Frameworks / Bibliotheken (wie Spring, Hibernate, Jackson, JUnit, Mockito) verursachen kann, die zur Laufzeit mit Ihrem Bytecode funktionieren.

Alles in allem würde ich es nicht vorziehen, mein Java mit Lombok "aufzupeppen".

Wollte Lomboks verwenden @ToString, sah sich jedoch bald zufälligen Kompilierungsfehlern bei der Neuerstellung des Projekts in Intellij IDEA gegenüber. Musste mehrmals auf Kompilieren klicken, bevor die inkrementelle Kompilierung erfolgreich abgeschlossen werden konnte.

Versuchte sowohl lombok 1.12.2 als auch 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.

Musste generierte Methoden manuell aus delomboked Quelle kopieren und lombok bis zu besseren Zeiten auf Eis legen.

Aktualisieren

Das Problem tritt nur bei aktivierter paralleler Kompilierung auf.

Problem behoben: https://github.com/rzwitserloot/lombok/issues/648

Aktualisieren

mplushnikov kommentierte am 30. Januar 2016:

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

Aktualisieren

Ich würde wärmstens empfehlen, wenn möglich von Java + Lombok zu Kotlin zu wechseln . Da es von Grund auf alle Java-Probleme gelöst hat, die Lombok zu umgehen versucht.

Ich habe ein Problem mit Lombok und Jackson CSV festgestellt , als ich mein Objekt (Java Bean) in eine CSV-Datei gemarshallt habe und Spalten dupliziert wurden. Dann habe ich Lomboks @ Data-Annotation entfernt und das Marshalling hat einwandfrei funktioniert.

Ich kann es nicht empfehlen. Früher habe ich es verwendet, aber als ich mit NetBeans 7.4 arbeitete, hat es meine Codes durcheinander gebracht. Ich muss Lombok in allen Dateien in meinen Projekten entfernen. Es gibt Delombok, aber wie kann ich sicher sein, dass es meine Codes nicht verschraubt? Ich muss Tage damit verbringen, Lombok zu entfernen und zu normalen Java-Stilen zurückzukehren. Ich bin einfach zu scharf ...

Ich habe noch nicht versucht, Lombok zu verwenden - es ist / war das nächste auf meiner Liste, aber es hört sich so an, als hätte Java 8 erhebliche Probleme verursacht, und seit einer Woche waren noch Abhilfemaßnahmen im Gange. Meine Quelle dafür ist https://code.google.com/p/projectlombok/issues/detail?id=451 .