Czy korzystanie z Project Lombok jest bezpieczne? [Zamknięte]

Jeśli nie wiesz, Project Lombok pomaga w niektórych irytujących kwestiach związanych z Javą w takich rzeczach, jak generowanie getterów i setterów z adnotacjami, a nawet proste generowanie JavaBean z @Data . To może mi naprawdę pomóc, szczególnie w 50 różnych obiektach eventowych, w których masz do 7 różnych pól, które trzeba zbudować i ukryć za pomocą getterów. Dzięki temu mogłem usunąć prawie tysiąc wierszy kodu.

Martwię się jednak, że na dłuższą metę będzie to żałosna decyzja. Flamewars wybuchnie na ##Java Freenodekanale, kiedy o tym wspomnę, pod warunkiem, że fragmenty kodu wprowadzą zamieszanie w potencjalnych pomocników, ludzie będą narzekać na brak JavaDoc , a przyszłe podmioty zatwierdzające mogą i tak je usunąć. Naprawdę podobałoby mi się to, co pozytywne, ale martwię się o to, co negatywne.

Więc: Czy bezpiecznie jest używać Lombok w każdym projekcie, małym lub dużym? Czy pozytywne efekty są warte negatywów?

Wygląda na to, że już zdecydowałeś, że Project Lombok zapewnia znaczne korzyści techniczne dla proponowanego nowego projektu. (Dla jasności od samego początku nie mam konkretnych poglądów na temat projektu Lombok, tak czy inaczej.)

Zanim użyjesz Project Lombok (lub innej technologii zmieniającej grę) w jakimś projekcie (open source lub w inny sposób), musisz upewnić się, że interesariusze projektu wyrażają na to zgodę. Dotyczy to programistów i wszelkich ważnych użytkowników (np. Oficjalnych lub nieformalnych sponsorów).

Wspominasz o tych potencjalnych problemach:

Flamewars wybuchnie na kanale ## Java Freenode, kiedy o tym wspomnę,

Łatwy. Zignoruj ​​/ nie bierz udziału w flamewars lub po prostu powstrzymaj się od wspominania o Lombok.

udostępnianie fragmentów kodu dezorientuje potencjalnych pomocników,

Jeśli strategia projektu polega na użyciu Lombok, potencjalni pomocnicy będą musieli się do tego przyzwyczaić.

ludzie będą narzekać na brak JavaDoc,

To jest ich problem. Nikt przy zdrowych zmysłach nie próbuje rygorystycznie stosować reguł kodu źródłowego / dokumentacji swojej organizacji do oprogramowania open source innych firm. Zespół projektowy powinien mieć swobodę ustalania standardów kodu źródłowego / dokumentacji, które są odpowiednie dla używanej technologii.

( OBSERWUJĄCY - programiści Lombok uznają, że nie generowanie komentarzy javadoc dla zsyntetyzowanych metod pobierających i ustawiających jest problemem. Jeśli jest to poważny problem dla twojego projektu (projektów), jedną z alternatyw jest stworzenie i przesłanie łaty Lombok, aby rozwiązać ten problem. )

a przyszli zleceniodawcy i tak mogą to wszystko usunąć.

To nie jest włączone! Jeśli uzgodnioną strategią projektu jest użycie Lombok, wówczas zleceniodawcy, którzy bezkarnie de-Lombok kodują, powinni zostać ukarani, aw razie potrzeby wycofać swoje prawa do zatwierdzania.

Oczywiście zakłada to, że masz wpisowe od interesariuszy ... w tym programistów. Zakłada się, że jesteś gotów argumentować swoją sprawę i odpowiednio radzić sobie z nieuchronnie odmiennymi głosami.

Właśnie zacząłem używać Lombok dzisiaj. Do tej pory mi się podobało, ale jedną wadą, o której nie wspomniałem, było wsparcie refaktoryzacji.

Jeśli masz klasę opatrzoną adnotacjami @Data, wygeneruje ona dla ciebie funkcje pobierające i ustawiające na podstawie nazw pól. Jeśli użyjesz jednego z tych modułów pobierających w innej klasie, a następnie zdecydujesz, że pole ma słabą nazwę, nie znajdzie zastosowań tych modułów pobierających i ustawiających i zastąpi starą nazwę nową nazwą.

Wyobrażam sobie, że trzeba by to zrobić za pomocą wtyczki IDE, a nie przez Lombok.

AKTUALIZACJA (22 stycznia 2013 r.)
Po 3 miesiącach używania Lombok nadal polecam go do większości projektów. Znalazłem jednak kolejną wadę podobną do powyższej.

Jeśli masz klasę, powiedzmy, MyCompoundObject.javaże ma 2 członków, obaj z adnotacjami @Delegate, powiedz myWidgetsi myGadgets, kiedy dzwonisz myCompoundObject.getThingies()z innej klasy, nie można wiedzieć, czy jest delegowana do Widgetlub Gadgetponieważ nie możesz już przeskakiwać do źródła w IDE.

Korzystanie z Eclipse „Generuj metody delegowania ...” zapewnia tę samą funkcjonalność, jest równie szybkie i zapewnia przeskakiwanie źródła. Minusem jest to, że zaśmieca twoje źródło kodem, który odwraca uwagę od ważnych rzeczy.

AKTUALIZACJA 2 (26 lutego 2013 r.)
Po 5 miesiącach nadal używamy Lombok, ale mam jeszcze inne problemy. Brak deklarowanego gettera i settera może być irytujący, gdy próbujesz zapoznać się z nowym kodem.

Na przykład, jeśli widzę metodę wywoływaną, getDynamicCols()ale nie wiem, o co chodzi, mam dodatkowe przeszkody, aby przeskoczyć, aby określić cel tej metody. Niektóre przeszkody to Lombok, niektóre brak inteligentnej wtyczki Lombok. Przeszkody obejmują:

• Brak JavaDocs. Gdybym javadoc pole, mam nadzieję, że getter i setter odziedziczą javadoc przez krok kompilacji Lombok.
• Przejdź do definicji metody przeskakuje mnie do klasy, ale nie do właściwości, która wygenerowała getter. To jest problem z wtyczką.
• Oczywiście nie możesz ustawić punktu przerwania w module pobierającym / ustawiającym, chyba że wygenerujesz lub zakodujesz metodę.
• UWAGA: Wyszukiwanie referencyjne nie stanowi problemu, tak jak na początku myślałem. Musisz jednak użyć perspektywy, która umożliwia widok Konspektu. Nie stanowi problemu dla większości programistów. Mój problem polegał na tym, że korzystam z Mylyn, który filtrował mój Outlinewidok, więc nie widziałem metod. Brak wyszukiwania referencji. Jeśli chcę zobaczyć, kto dzwoni getDynamicCols(args...), muszę wygenerować lub zakodować seter, aby móc wyszukiwać referencje.

AKTUALIZACJA 3 (7 marca 13)
Chyba nauczyłem się korzystać z różnych sposobów robienia rzeczy w Eclipse. W rzeczywistości można ustawić warunkowy punkt przerwania (BP) w metodzie generowanej przez Lombok. Korzystając z Outlinewidoku, możesz kliknąć metodę prawym przyciskiem myszy Toggle Method Breakpoint. Następnie po naciśnięciu BP można użyć Variableswidoku debugowania, aby zobaczyć, jak wygenerowana metoda nazywała parametry (zwykle takie same jak nazwa pola), a na koniec, użyj Breakpointswidoku, aby kliknąć BP prawym przyciskiem myszy i wybrać, Breakpoint Properties...aby dodać warunek. Miły.

AKTUALIZACJA 4 (16 sierpnia 13)
Netbeans nie lubi, gdy aktualizujesz swoje zależności Lombok w Maven pom. Projekt nadal się kompiluje, ale pliki są oznaczane jako zawierające błędy kompilacji, ponieważ nie widzi metod, które tworzy Lombok. Wyczyszczenie pamięci podręcznej Netbeans rozwiązuje problem. Nie jestem pewien, czy istnieje opcja „Wyczyść projekt”, tak jak w Eclipse. Drobny problem, ale chciałem go poinformować.

AKTUALIZACJA 5 (17 stycznia 14)
Lombok nie zawsze dobrze gra z Groovy, a przynajmniej z groovy-eclipse-compiler. Może być konieczne obniżenie wersji kompilatora. Maven Groovy i Java + Lombok

AKTUALIZACJA 6 (26 czerwca 14)
Słowo ostrzeżenia. Lombok jest nieco uzależniający i jeśli pracujesz nad projektem, z którego z jakiegoś powodu nie możesz go użyć, zirytuje cię to. Lepiej, żebyś nigdy go nie używał.

AKTUALIZACJA 7 (23 lipca 14)
To jest trochę interesująca aktualizacja, ponieważ bezpośrednio odnosi się do bezpieczeństwa przyjęcia Lomboka, o które prosiła OP.

Od wersji 1.4 @Delegateadnotacja została zdegradowana do stanu eksperymentalnego. Szczegóły są udokumentowane na ich stronie ( dokumenty delegatów Lombok ).

Chodzi o to, że jeśli korzystasz z tej funkcji, opcje wycofywania są ograniczone. Widzę opcje jako:

• Usuń ręcznie @Delegate adnotacje i wygeneruj / podaj kod delegowany. Jest to trochę trudniejsze, jeśli używasz atrybutów w adnotacji.
• Delombokuj pliki z @Delegateadnotacjami i być może dodaj je ponownie w odpowiednich adnotacjach.
• Nigdy nie aktualizuj Lombok ani nie utrzymuj rozwidlenia (lub korzystaj z funkcji eksperymentalnych).
• Delombok cały projekt i przestań używać Lombok.

O ile mi wiadomo, Delombok nie ma opcji usuwania podzbioru adnotacji ; to wszystko albo nic, przynajmniej w kontekście pojedynczego pliku. Otworzyłem bilet z prośbą o tę funkcję z flagami Delombok, ale nie spodziewałbym się tego w najbliższej przyszłości.

AKTUALIZACJA 8 (20 października 2014 r.)
Jeśli jest to opcja dla Ciebie, Groovy oferuje większość takich samych korzyści Lombok, a także mnóstwo innych funkcji, w tym @Delegate . Jeśli uważasz, że trudno ci będzie sprzedać ten pomysł mocom, które są, spójrz na adnotację @CompileStaticlub @TypeCheckedadnotację, aby sprawdzić, czy to może pomóc twojej sprawie. W rzeczywistości głównym celem wydania Groovy 2.0 było bezpieczeństwo statyczne .

AKTUALIZACJA 9 (1 września 15)
Lombok jest nadal aktywnie utrzymywany i rozwijany , co dobrze wróży poziomowi bezpieczeństwa adopcji. W @Builder adnotacje jest jednym z moich ulubionych nowych funkcji.

AKTUALIZACJA 10 (17 listopada 15)
To może nie wydawać się bezpośrednio związane z pytaniem PO, ale warto się nim podzielić. Jeśli szukasz narzędzi, które pomogą Ci zmniejszyć ilość kodu, który piszesz, możesz także sprawdzić Google Auto - w szczególności AutoValue . Jeśli spojrzysz na ich zjeżdżalnię , wypisz Lombok jako możliwe rozwiązanie problemu, który próbują rozwiązać. Wady, które wymieniają dla Lombok to:

• Wstawiony kod jest niewidoczny (nie możesz „zobaczyć” metod, które generuje) [zredaguj notatkę - właściwie możesz, ale wymaga tylko dekompilatora]
• Hacki kompilatora są niestandardowe i delikatne
• „Naszym zdaniem twój kod nie jest już tak naprawdę językiem Java”

Nie jestem pewien, jak bardzo zgadzam się z ich oceną. Biorąc pod uwagę wady AutoValue, które są udokumentowane na slajdach, będę trzymać się Lomboka (jeśli Groovy nie jest opcją).

AKTUALIZACJA 11 (8 lutego 16).
Dowiedziałem się, że Spring Roo ma podobne adnotacje . Byłem trochę zaskoczony, gdy dowiedziałem się, że Roo wciąż jest rzeczą, a znalezienie dokumentacji dla adnotacji jest nieco trudne. Usunięcie również nie wygląda tak łatwo jak de-lombok. Lombok wydaje się bezpieczniejszym wyborem.

AKTUALIZACJA 12 (17 lutego 2016)
Próbując znaleźć uzasadnienie, dlaczego bezpiecznie sprowadzić Lombok do projektu, nad którym aktualnie pracuję, znalazłem kawałek złota, który został dodany v1.14- System konfiguracji ! Oznacza to, że możesz skonfigurować projekt, aby wyłączyć niektóre funkcje, które Twój zespół uzna za niebezpieczne lub niepożądane. Co więcej, może również tworzyć konfigurację specyficzną dla katalogu z różnymi ustawieniami. To jest niesamowite.

AKTUALIZACJA 13 (4 października 16).
Jeśli to dla ciebie ważne, Oliver Gierke uznał, że bezpiecznie jest dodać Lombok do Spring Data Rest .

AKTUALIZACJA 14 (26 września 17)
Jak wskazał @gavenkoa w komentarzach do pytania PO, obsługa kompilatora JDK9 nie jest jeszcze dostępna (numer 985). Wygląda na to, że zespół Lombok nie będzie łatwo go obejść.

AKTUALIZACJA 15 (26 marca 18)
Dziennik zmian Lombok wskazuje od 1.1.16.20 „ Kompilowanie lomboka na JDK1.9 jest teraz możliwe ”, chociaż # 985 jest nadal otwarty.

Zmiany w celu dostosowania JDK9 wymagały jednak pewnych przełomowych zmian; wszystkie odizolowane od zmian w ustawieniach domyślnych konfiguracji. To trochę niepokojące, że wprowadzili przełomowe zmiany, ale wersja tylko zderzyła się z numerem wersji „Przyrostowej” (od wersji 1.16.18 do wersji 1.16.20). Ponieważ ten post dotyczył bezpieczeństwa, jeśli masz yarn/npmpodobny system kompilacji, który automatycznie aktualizuje się do najnowszej wersji przyrostowej, możesz być w stanie rude przebudzenie.

AKTUALIZACJA 16 (9 stycznia 19)

Wygląda na to, że problemy z JDK9 zostały rozwiązane i Lombok współpracuje z JDK10, a nawet JDK11, o ile wiem.

Jedną z rzeczy, które zauważyłem, że dotyczy to kwestii bezpieczeństwa, jest fakt, że dziennik zmian z wersji 1.18.2 do wersji 1.18.4 wymienia dwie pozycje jako BREAKING CHANGE!? Nie jestem pewien, jak zmienia się przełom w aktualizacji „łaty” semver. Może to stanowić problem, jeśli korzystasz z narzędzia, które automatycznie aktualizuje wersje poprawek.

Śmiało, użyj Lombok, w razie potrzeby możesz później „delombokować” swój kod http://projectlombok.org/features/delombok.html

Osobiście (a zatem subiektywnie) odkryłem, że użycie Lombok sprawia, że ​​mój kod jest bardziej ekspresyjny w stosunku do tego, co próbuję osiągnąć w porównaniu z IDE / własnymi implementacjami skomplikowanych metod, takich jak hashcode i równość.

Podczas używania

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

znacznie łatwiej jest zachować spójność Equals & HashCode i śledzić, które pola są oceniane, niż jakakolwiek implementacja IDE / własna. Jest to szczególnie ważne, gdy nadal regularnie dodajesz / usuwasz pola.

To samo dotyczy @ToStringadnotacji i jej parametrów, które w jasny sposób przekazują pożądane zachowanie dotyczące uwzględnionych / wykluczonych pól, użycia getterów lub dostępu do pola i czy nie należy dzwonić super.toString().

I ponownie, dodając adnotacje do całej klasy za pomocą @Getterlub@Setter(AccessLevel.NONE) (i opcjonalnie przesłonięcie jakichkolwiek rozbieżnych metod) natychmiast staje się jasne, jakie metody będą dostępne dla pól.

Korzyści trwają i trwają ..

Moim zdaniem nie chodzi o redukcję kodu, ale o wyraźne komunikowanie tego, co chcesz osiągnąć, zamiast konieczności rozpracowywania go na podstawie Javadoc lub implementacji. Zredukowany kod po prostu ułatwia wykrycie wszelkich implementacji metod rozbieżnych.

Lombok jest świetny, ale ...

Lombok łamie zasady przetwarzania adnotacji, ponieważ nie generuje nowych plików źródłowych. Oznacza to, że nie można go używać z innymi procesorami adnotacji, jeśli spodziewają się, że pobrane / ustawiające lub cokolwiek innego istnieje.

Przetwarzanie adnotacji przebiega w szeregu rund. W każdej rundzie każda z nich ma swoją kolej do uruchomienia. Jeśli jakieś nowe pliki Java zostaną znalezione po zakończeniu rundy, rozpoczyna się kolejna runda. W ten sposób kolejność procesorów adnotacji nie ma znaczenia, jeśli generują tylko nowe pliki. Ponieważ lombok nie generuje żadnych nowych plików, żadne nowe rundy nie są uruchamiane, więc niektóre AP oparte na kodzie lombok nie działają zgodnie z oczekiwaniami. Było to dla mnie ogromne źródło bólu podczas korzystania z mapstruct, a delombokowanie nie jest przydatną opcją, ponieważ niszczy numery linii w logach.

W końcu zhakowałem skrypt kompilacji do pracy zarówno z lombokiem, jak i mapstruct. Ale chcę rzucić lombok ze względu na jego hackowanie - przynajmniej w tym projekcie. Cały czas używam lomboka do innych celów.

Przeczytałem kilka opinii na temat Lomboka i faktycznie używam go w niektórych projektach.

Cóż, przy pierwszym kontakcie z Lombok miałem złe wrażenie. Po kilku tygodniach zaczęło mi się to podobać. Ale po kilku miesiącach odkryłem wiele drobnych problemów z jego używaniem. Moje ostatnie wrażenie na temat Lomboka nie jest już tak pozytywne.

Moje powody, by myśleć w ten sposób:

• Zależność wtyczki IDE . Obsługa IDE dla Lombok odbywa się poprzez wtyczki. Nawet działając dobrze przez większość czasu, zawsze jesteś zakładnikiem tych wtyczek, które będą utrzymywane w przyszłych wydaniach IDE, a nawet w wersji językowej (Java 10+ przyspieszy rozwój języka). Na przykład próbowałem zaktualizować z Intellij IDEA 2017.3 do 2018.1 i nie mogłem tego zrobić, ponieważ wystąpił problem z faktyczną wersją wtyczki lombok i musiałem czekać na aktualizację wtyczki ... Jest to również problem, jeśli chciałbym użyć bardziej alternatywnego IDE, które nie ma żadnej obsługi wtyczek Lombok.
• Problem „Znajdź zastosowania”. . Korzystając z Lombok, nie widzisz wygenerowanych metod pobierających, ustawiających, konstruktorów, konstruktorów itp. Tak więc, jeśli planujesz dowiedzieć się, gdzie te metody są używane w twoim projekcie przez IDE, nie możesz tego zrobić tylko patrząc dla klasy, która jest właścicielem tych ukrytych metod.
• Tak łatwe, że programiści nie chcą złamać enkapsulacji . Wiem, że Lombok nie jest tak naprawdę problemem. Widziałem jednak większą skłonność programistów do nie kontrolowania, które metody powinny być widoczne, czy nie. Tak więc wiele razy po prostu kopiują i wklejają @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorblok adnotacji, nie zastanawiając się, jakie metody naprawdę należy ujawnić.
• Builder Obssession ©. Wymyśliłem to imię (zejdź, Martin Fowler). Żartuje, że Konstruktor jest tak łatwy do utworzenia, że ​​nawet jeśli klasa ma tylko dwa parametry, których programiści wolą używać @Builderzamiast konstruktora lub statycznej metody konstruktora. Czasami nawet próbują stworzyć Konstruktora wewnątrz Konstruktora lombok, tworząc dziwne sytuacje takie jak MyClass.builder().name("Name").build().create().
• Bariery przy refaktoryzacji . Jeśli używasz na przykład a @AllArgsConstructori chcesz dodać jeszcze jeden parametr do konstruktora, IDE nie pomoże ci dodać tego dodatkowego parametru we wszystkich miejscach (głównie testach), które tworzą instancję klasy.
• Mieszanie Lomboka z konkretnymi metodami . Nie można używać Lombok we wszystkich scenariuszach, aby utworzyć getter / setter / etc. Tak więc zobaczysz, że te dwa podejścia mieszają się w kodzie. Przyzwyczajasz się do tego po pewnym czasie, ale czujesz się jak włamanie do języka.

Podobnie jak w przypadku innej odpowiedzi: jeśli jesteś zły na gadatliwość Javy i użyj Lombok, aby sobie z tym poradzić, wypróbuj Kotlin.

Istnieje również ryzyko związane z długoterminową konserwacją. Po pierwsze, polecam przeczytać o tym, jak faktycznie działa Lombok, np. Niektóre odpowiedzi od jego twórców tutaj .

Oficjalna strona zawiera także listę wad , w tym cytat Reiniera Zwitserloota:

To totalny hack. Korzystanie z niepublicznego interfejsu API. Zuchwałe rzutowanie (wiedząc, że procesor adnotacji działający w javac otrzyma instancję JavacAnnotationProcessor, która jest wewnętrzną implementacją AnnotationProcessor (interfejs), który tak się składa, że ​​ma kilka dodatkowych metod, które są używane do uzyskania w czasie rzeczywistym AST) .

W przypadku Eclipse jest to prawdopodobnie gorsze (i jeszcze bardziej niezawodne) - agent Java jest używany do wstrzykiwania kodu do klasy gramatyki i parsera Eclipse, która jest oczywiście całkowicie niepublicznym API i całkowicie niedostępna.

Gdybyś mógł zrobić to, co robi Lombok ze standardowym API, zrobiłbym to w ten sposób, ale nie możesz. Mimo to, o ile jest to warte, opracowałem wtyczkę eclipse dla Eclipse v3.5 działającą na java 1.6, i bez żadnych zmian działało to również na eclipse v3.4 działającej na java 1.5, więc nie jest całkowicie delikatna.

Podsumowując, podczas gdy Lombok może zaoszczędzić trochę czasu na rozwój, jeśli istnieje niekompatybilna aktualizacja javac (np. Ograniczenie podatności na zagrożenia) Lombok może utknąć w starej wersji Javy, podczas gdy programiści starają się zaktualizować ich użycie wewnętrzne interfejsy API. To, czy jest to poważne ryzyko, zależy oczywiście od projektu.

Wiem, że się spóźniłem, ale nie mogę oprzeć się pokusie: każdy, kto lubi Lomboka, powinien także spojrzeć na Scalę. Wiele dobrych pomysłów, które można znaleźć w Lombok, jest częścią języka Scala.

Na twoje pytanie: zdecydowanie łatwiej jest zachęcić programistów do wypróbowania Lomboka niż Scali. Spróbuj, a jeśli im się spodoba, spróbuj Scali.

Tylko jako zastrzeżenie: ja też lubię Javę!

Używam Lombok w prawie wszystkich moich projektach przez rok, ale niestety go usunąłem. Na początku był to bardzo czysty sposób rozwoju, ale utworzenie środowiska programistycznego dla nowych członków zespołu nie jest bardzo łatwe i proste. Kiedy stał się bólem głowy, właśnie go usunąłem. Ale jest to dobra robota i wymaga nieco prostoty w konfiguracji.

Kiedy pokazałem projekt zespołowi, entuzjazm był duży, więc myślę, że nie powinieneś bać się reakcji zespołu.

• Jeśli chodzi o ROI, integracja jest łatwa i nie wymaga zmiany kodu w podstawowej formie. (po prostu dodając jedną adnotację do swojej klasy)

• I na koniec, jeśli zmienisz zdanie, możesz uruchomić unlombok lub pozwolić twojemu IDE stworzyć te setery, gettery i lekarze (o których myślę, że nikt nie zapyta, kiedy zobaczą, jak jasne staje się twoje pojęcie)

Moje zdanie na temat Lombok polega na tym, że zapewnia on jedynie skróty do pisania kodu Java.
Jeśli chodzi o używanie skrótów do pisania bolilerplate kodu Java, polegałbym na takich funkcjach dostarczanych przez IDE - podobnie jak w Eclipse, możemy przejść do menu Źródło> Generuj Gettery i Settery do generowania getterów i setterów.
W tym przypadku nie polegałbym na bibliotece takiej jak Lombok:

1. Zanieczyszcza twój kod za pomocą pośredniej warstwy alternatywnej składni (czytaj @Getter,@Setter itp adnotacji). Zamiast uczyć się alternatywnej składni Java, przeszedłbym na inny język, który natywnie zapewnia składnię podobną do Lomboka.
2. Lombok wymaga użycia IDE obsługiwanego przez Lombok do pracy z Twoim kodem. Zależność ta stwarza znaczne ryzyko dla każdego nietrywialnego projektu. Czy projekt Lombok o otwartym kodzie źródłowym ma wystarczającą ilość zasobów, aby nadal zapewniać obsługę różnych wersji szerokiej gamy dostępnych Java IDE?
3. Czy projekt Lombok o otwartym kodzie źródłowym ma wystarczające zasoby, aby nadal obsługiwać nowsze wersje Javy, które będą dostępne w przyszłości?
4. Niepokoi mnie również to, że Lombok może wprowadzać problemy ze zgodnością z powszechnie używanymi frameworkami / bibliotekami (takimi jak Spring, Hibernate, Jackson, JUnit, Mockito), które działają z twoim kodem bajtowym w czasie wykonywania.

Podsumowując, nie wolałbym „urozmaicić” mojej Javy za pomocą Lomboka.

Chciałem użyć lomboka @ToString ale wkrótce wystąpiły przypadkowe błędy kompilacji podczas przebudowy projektu w Intellij IDEA. Musiałem nacisnąć kompilację kilka razy, aby kompilacja przyrostowa mogła zakończyć się sukcesem.

Próbowałem zarówno lombok 1.12.2, jak i 0.9.3 z Intellij IDEA 12.1.6 i 13.0 bez żadnej wtyczki lombok pod jdk 1.6.0_39 i 1.6.0_45.

Musiałem ręcznie skopiować wygenerowane metody z delombokowanego źródła i zawiesić lombok do lepszych czasów.

Aktualizacja

Problem występuje tylko przy włączonej kompilacji równoległej.

Zgłoszony problem: https://github.com/rzwitserloot/lombok/issues/648

Aktualizacja

mplushnikov skomentował 30 stycznia 2016:

W nowszej wersji Intellij nie ma już takich problemów. Myślę, że można to tutaj zamknąć.

Aktualizacja

Jeśli to możliwe, zdecydowanie zaleciłbym przejście z Java + Lombok na Kotlin . Po rozwiązaniu od podstaw wszystkich problemów Java, które Lombok próbuje obejść.

Napotkałem problem z Lombok i Jackson CSV , kiedy marshalizowałem mój obiekt (java bean) do pliku CSV, kolumn gdzie zostały zduplikowane, a następnie usunąłem adnotację @Data Lombok i marshalizing działało dobrze.

Nie polecam tego. Kiedyś go używałem, ale potem, kiedy pracowałem z NetBeans 7.4, bałaganiłem moje kody. Muszę usunąć lombok ze wszystkich plików w moich projektach. Jest delombok, ale jak mogę się upewnić, że nie spieprzy moich kodów. Muszę spędzać dni, aby usunąć lombok i wrócić do zwykłych stylów Java. Po prostu jestem zbyt ostry ...

Nie próbowałem jeszcze używać Lombok - jest / był następny na mojej liście, ale wygląda na to, że Java 8 spowodował poważne problemy, a prace naprawcze były nadal w toku od tygodnia. Moim źródłem jest https://code.google.com/p/projectlombok/issues/detail?id=451 .