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 Freenode
kanale, 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?
javac
w celu otwarcia dostępu dosun.*
klas wewnętrznych ((Odpowiedzi:
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:
Łatwy. Zignoruj / nie bierz udziału w flamewars lub po prostu powstrzymaj się od wspominania o Lombok.
Jeśli strategia projektu polega na użyciu Lombok, potencjalni pomocnicy będą musieli się do tego przyzwyczaić.
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. )
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.
źródło
getCreationDate
,getDueDate
. Nazewnictwo przebija komentarze tam, gdzie to możliwe.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
, powiedzmyWidgets
imyGadgets
, kiedy dzwoniszmyCompoundObject.getThingies()
z innej klasy, nie można wiedzieć, czy jest delegowana doWidget
lubGadget
ponieważ 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ą:Outline
widok, więc nie widziałem metod. Brak wyszukiwania referencji. Jeśli chcę zobaczyć, kto dzwonigetDynamicCols(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
Outline
widoku, możesz kliknąć metodę prawym przyciskiem myszyToggle Method Breakpoint
. Następnie po naciśnięciu BP można użyćVariables
widoku debugowania, aby zobaczyć, jak wygenerowana metoda nazywała parametry (zwykle takie same jak nazwa pola), a na koniec, użyjBreakpoints
widoku, 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 + LombokAKTUALIZACJA 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
@Delegate
adnotacja 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:
@Delegate
adnotacje i wygeneruj / podaj kod delegowany. Jest to trochę trudniejsze, jeśli używasz atrybutów w adnotacji.@Delegate
adnotacjami i być może dodaj je ponownie w odpowiednich adnotacjach.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ę
@CompileStatic
lub@TypeChecked
adnotację, 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:
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/npm
podobny 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.źródło
UPDATE 6
czuje się bardzo jak Scala :)Śmiało, użyj Lombok, w razie potrzeby możesz później „delombokować” swój kod http://projectlombok.org/features/delombok.html
źródło
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
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
@ToString
adnotacji 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ą
@Getter
lub@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.
źródło
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.
źródło
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:
@Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor
blok adnotacji, nie zastanawiając się, jakie metody naprawdę należy ujawnić.@Builder
zamiast konstruktora lub statycznej metody konstruktora. Czasami nawet próbują stworzyć Konstruktora wewnątrz Konstruktora lombok, tworząc dziwne sytuacje takie jakMyClass.builder().name("Name").build().create()
.@AllArgsConstructor
i 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.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.
źródło
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:
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.
źródło
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ę!
źródło
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.
źródło
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)
źródło
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:
@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.Podsumowując, nie wolałbym „urozmaicić” mojej Javy za pomocą Lomboka.
źródło
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
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ść.
źródło
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.
źródło
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 ...
źródło
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 .
źródło