Spotkałem się kilkukrotnie z opinią, że #lombok to gówno i wypad mi z tym z projektu. Niestety nikt nie był w stanie mi wyjaśnić co ma przeciwko automatycznie generowanym getterom i builderom, tylko tyle, że gówno to jedno wielkie. Raz jeden ziomek powiedział, że autovalue lepsze ale nie ogarnąłem dlaczego. Więc jak to jest? Czemu przeciwnicy lomboka go tak bardzo nie lubią?
@dupaztrupa generalnie jak piszesz w notatniku to przydaje sie, ale w IDE na ogol wstawienie getterow i setterow to dwa klikniecia
@Getter @Setter raczej bezpieczne, @Builder sie przydaje ale juz @Data radze omijac bo generuje toString i hashCode ktore sa moge generowac bugi (swoja droga, w IntelliJ IDEA skrot ctrl + Insert generuje metody o tej samej zawartosci, wiec nie wiem co tak wszyscy najezdzaja, zawsze mozna dac po prostu to @
@dupaztrupa na Stockoverflow jest temat gdzie dokładnie zostało wyjaśnione. Głównie co pamiętam chodzi o to że lombok korzysta z prywatnego kodu API Javy Plus modyfikacja kodu bajtowego.
@Bruno_: ale generowanie ręcznie jest mega upierdliwe. Dodasz czy usuniesz pole I już getter, setter, tostring, i inne trzeba zmienić. Czasem, zwłaszcza w początkowej fazie, projekt, entity I api zmienia sie bardzo dynamicznie. Przegenerowywanie tego wszystkiego jest mega upierdliwe
Tu masz wątek o tym czemu maintainer jhipstera nie chce tego szajsu - polecam zwrócić uwagę na fragment "triggers bugs in jvm". Na pewno chcesz to mieć w komercyjnym projekcie? Powiesz potem klientowi z czystym sumieniem że machnąłeś mu dobrze napisany i stabilny projekt?
@Myzreal: sporo przygód miał ten koleś z lombokiem. Ja osobiście miałem tylko taką, ze z Java 9 czy tam 10 nie działo przez jakiś czas. Patrząc na głosy społeczności (lajki) ludzie lubią profity jakie wynikają z używania lomboka. Szkoda, ze nie napisał czegoś więcej na temat Buga w jvm i crasha ci
@dupaztrupa: Dobra przeklejam z poprzedniego wątku:
Działanie Lomboka opiera się na "hacku" - wykorzystuje nieudokumentowane API do generowania kodu. Jakie zagrożenia się za tym kryją to nie muszę mówić chyba, wystarczy wspomnieć że nieudokumentowane API mogą być usunięte w dowolnej chwili.
W prywatnym projekcie owszem, sam używam. W komercyjnym - w życiu. Nie chce być tym typem którego git blame wskaże za 10 lat jak się to #!$%@? i jakiś doświadczony
@dupaztrupa: tak jak się spodziewałem, nikt Ci nie podał żadnego konkretnego argumentu, oprócz jakichś ogólników i linka gdzie ktoś 3 lata temu narzekał, że lombok mu zabił CI xDD. Osobiście, miałem z lombokiem problem tylko raz, gdy przy budowaniu projektu zaczęły kolidować różne annotation processory (lombokowy i odpowiedzialny za generowanie JPA metamodel).
@Bruno_: więc to chyba była wina samej klasy a nie lomboka, skoro IDE też generowało "zły" toString/hashcode. Taki
@doubt no jak nie odróżniasz normalnej biblioteki code-only albo używającej przeznaczonych dla niej API z gwarancją stabilności od takiej, która używa niestabilnych API bez owej gwarancji, co dodatkowo jest na tyle nienormalne że każde ide musi mieć plugin żeby to zakumać to rzeczywiście nie mamy o czym dyskutować i temat wydaje się wyczerpany.
Już bym wolał zapiąć kotlina do kompilacji i pisać w nim data classes i używać ich potem z poziomu
@Myzreal: imo z ide słaby argument. Jak korzystasz z jakiś mapperów, querydsl czy pluginów mavenowych do jaxb (soap wiecznie popularny w korpo) to i tak ide musi ogarniać, że gdzieś tam podczas kompilacji jest generowany kod, wygenerować go i podpowiadać.
@doubt: Najczęstszy błąd. Występuje również gdy się klika alt insert w idei i nie patrzy na nic. Mało tego - w lomboku łatwiej to naprawić. Dodając exclude mówisz w prost, że tego nie chcesz. Natomiast usuwając z toStringa nie zostawiasz informacji, że jest problem (komentarz? xD) i kolejne osoba wygeneruje toString po dodaniu pola i klops od nowa. Niespodziewany exception na produkcji
@dupaztrupa: ja preferuję używać annotation processorów tak jak Gosling przykazał - piszę interfejsy, AP tworzy mi do tego źródła implementacji. Do wyboru jest kilka tooli - Immutables, AutoValue, pewnie jeszcze jakieś inne. Użycie lomboka zamiast tamtych dwóch nie ma w zasadzie żadnych ciekawszych zalet.
@Myzreal: jak prywatne api usunięte w każdej chwili? Tylko w przypadku aktualizacji. Ale równie dobrze po aktualizacji może przestać działać każda inna biblioteka wiec co to za argument?
@kebab-case Ja #!$%@?ę, bo publiczne API jest przeznaczone do tego żeby go używać a prywatne - nie. Wynika z tego szereg reperkusji, między innymi stabilność i gwarancja niezmienności bądź też kompatybilności. Tylko tyle i aż tyle, tak ciężko to zakumać?
@Myzreal: ale do kogo to mówisz? Bo chyba nie do mnie bo ja w ogóle nie poruszałem kwestii o których teraz mówisz. Odniosłem się do tego ze równie dobrze po aktualizacji może przestać działać każda inna biblioteka. Zaprzeczasz temu?
"delombokatyzacja" projektu to jest odpalenie jednego gola/taska w mavenie/gradlu
@doubt: Skoro tak prosto go zastąpić to po co go dodawać?
@dupaztrupa: częste błędy w połączeniu z obiektami domenowymi w hibernate - użycie w toString z polami które są ładowane lazy generuje exception. hashCode w ogóle nie przydatne w tym przypadku bo hashCode w takich obiektach powinien być implementowany dość specyficzne.
Problem z debugowaniem wygenerowanych metod/konstruktorów - w intellij i tak
@doubt: Skoro tak prosto go zastąpić to po co go dodawać?
@Koryntiusz: nie zastąpić a usunąć i zostać z boilerplate kodem. Lepszej alternatywy (oprócz pisania data klas w kotlinie) nie wymyślono.
Nawet jeżeli lombok przestanie działać z jakimś nowym releasem javy to i tak to jest ostatnia biblioteka, która mogłaby blokować migrację do nowszego jdk, bo w razie problemów można ją łatwo usunąć z projektu.
@doubt: W Springu nie raz się przydaje sprawdzić która implementacja jest wstrzykiwana albo żeby potwierdzić kolejność inicjalizacji komponentów. Nie zdarza się to często ale się zdarza.
Już prędzej update javy zablokuje ci spring czy inne biblioteki korzystające z magicznych libów do tworzenia kodu w locie (cglib, bytebuddy, javassist i inne).
@doubt: To chyba nie do mnie, ale skoro już mnie wywołałeś to wcześniej było wspomniane
Więc jak to jest? Czemu przeciwnicy lomboka go tak bardzo nie lubią?
#java #programowanie
@Getter @Setter raczej bezpieczne, @Builder sie przydaje ale juz @Data radze omijac bo generuje toString i hashCode ktore sa moge generowac bugi (swoja droga, w IntelliJ IDEA skrot ctrl + Insert generuje metody o tej samej zawartosci, wiec nie wiem co tak wszyscy najezdzaja, zawsze mozna dac po prostu to @
Przegenerowywanie tego wszystkiego jest mega upierdliwe
Tu masz wątek o tym czemu maintainer jhipstera nie chce tego szajsu - polecam zwrócić uwagę na fragment "triggers bugs in jvm". Na pewno chcesz to mieć w komercyjnym projekcie? Powiesz potem klientowi z czystym sumieniem że machnąłeś mu dobrze napisany i stabilny projekt?
Patrząc na głosy społeczności (lajki) ludzie lubią profity jakie wynikają z używania lomboka.
Szkoda, ze nie napisał czegoś więcej na temat Buga w jvm i crasha ci
Działanie Lomboka opiera się na "hacku" - wykorzystuje nieudokumentowane API do generowania kodu. Jakie zagrożenia się za tym kryją to nie muszę mówić chyba, wystarczy wspomnieć że nieudokumentowane API mogą być usunięte w dowolnej chwili.
W prywatnym projekcie owszem, sam używam. W komercyjnym - w życiu. Nie chce być tym typem którego git blame wskaże za 10 lat jak się to #!$%@? i jakiś doświadczony
@Bruno_: więc to chyba była wina samej klasy a nie lomboka, skoro IDE też generowało "zły" toString/hashcode. Taki
Już bym wolał zapiąć kotlina do kompilacji i pisać w nim data classes i używać ich potem z poziomu
@doubt: Najczęstszy błąd. Występuje również gdy się klika alt insert w idei i nie patrzy na nic. Mało tego - w lomboku łatwiej to naprawić. Dodając exclude mówisz w prost, że tego nie chcesz. Natomiast usuwając z toStringa nie zostawiasz informacji, że jest problem (komentarz? xD) i kolejne osoba wygeneruje toString po dodaniu pola i klops od nowa. Niespodziewany exception na produkcji
@doubt: Skoro tak prosto go zastąpić to po co go dodawać?
@dupaztrupa: częste błędy w połączeniu z obiektami domenowymi w hibernate - użycie w toString z polami które są ładowane lazy generuje exception. hashCode w ogóle nie przydatne w tym przypadku bo hashCode w takich obiektach powinien być implementowany dość specyficzne.
Problem z debugowaniem wygenerowanych metod/konstruktorów - w intellij i tak
@Koryntiusz: nie zastąpić a usunąć i zostać z boilerplate kodem. Lepszej alternatywy (oprócz pisania data klas w kotlinie) nie wymyślono.
Nawet jeżeli lombok przestanie działać z jakimś nowym releasem javy to i tak to jest ostatnia biblioteka, która mogłaby blokować migrację do nowszego jdk, bo w razie problemów można ją łatwo usunąć z projektu.
Już prędzej update javy zablokuje
@doubt: W Springu nie raz się przydaje sprawdzić która implementacja jest wstrzykiwana albo żeby potwierdzić kolejność inicjalizacji komponentów. Nie zdarza się to często ale się zdarza.
@doubt: To chyba nie do mnie, ale skoro już mnie wywołałeś to wcześniej było wspomniane