Hej
W tutorialu, z które aktualnie się uczę jest stosowany Lombok, pozwala on zlikwidować część powtarzalnego kodu.
Spotkałem się z wieloma opiniami, że jednak lepiej z niego nie korzystać. Chciałbym poznać Wasze doświadczenia z tym projektem i opinie nt. tego, czy powinno się tym w ogóle interesować w 2022 roku.
0
2
Wszystko jest dla ludzi.
Lombok skomplikowany nie jest a i tak często ludzie nie potrafią z niego korzystać (przepisują na pałę adnotacje które się np. pokrywają).
Ja w projekcie lomboka mam, działa, jeszcze nie sprawiał problemów.
6
To nie Lombok jest zły. To Java jest zła, bo rozwlekła. Lombok próbuje zrobić z Javy zwięzły język, ale dalej wygląda to jak potwórek, czyli więcej adnotacji niż kodu. A można wziąć Kotlina lub Scalę i mieć w standardzie języka to co daje Lombok i dużo więcej
2
"Naprawia" te cechy Javy, które są zużyte przez czas. Projektując w pierwszej połowie lat 199x tak się to widziało, ale czas leci do przodu - a świat javowski założył 100% kompatybilności ze starymi wersjami.
Jak jako student/absolwent sprzedawałem swojego fiata 126p, wielką zaletą dla nabywcy był cały bagażnik części zapasowych, pompek, rurek, drutów itd To był taki lombook
Właściwie to samo daje dobre IDE - choć w inny sposób, dłuższy, choć nie klepany palcem, kod siedzi w sursach: generowanie konstruktorów, toString'a itd Kod dłuższy, ale np da się postawić breakpoint. Osobiście wolę.
jesli pytasz na zasadzie samorozwoju: zmienić język, zainteresować się Kotlinem.
jesli korporacyjnej konieczności - nie dyskutuję z tym, mus to mus.
0
KamilAdam napisał(a):
To Java jest zła, bo rozwlekła.
Nie tylko w bezwzględnej długości kodu problem, to bym wybaczył, ale w zingnorowaniu istotnych potrzeb. *)
Np nigdy nie wyspecyfikowano syntaktycznie wydzielonej property / geterea / setera, i to co mamy to jest "by convention". A to zrobiło sie bardzo ważne przez Java Beany, "bardzo ważną rzecz" mamy by convention.
Libki próbujące z klasy "zgadnąć" strukturę/nazwę property/beanów każda robi to inaczej
Młodszy brat (C#) sie tym zajął i z propertisami jest bardzo dobrze
*) choć nic nie równa się z komitetem standaryzującym C++
0
Czy Javę by ratowało (częściowe) zerwanie kompatybilnosci, np po 3 numerkach wersji / 10 latach odesłanie deprecated w kosmos ... może, ale tak nie jest.
2
programista60kPLN napisał(a):
Hej
W tutorialu, z które aktualnie się uczę jest stosowany Lombok, pozwala on zlikwidować część powtarzalnego kodu.
Spotkałem się z wieloma opiniami, że jednak lepiej z niego nie korzystać. Chciałbym poznać Wasze doświadczenia z tym projektem i opinie nt. tego, czy powinno się tym w ogóle interesować w 2022 roku.
Niektórzy programiści są zmuszeni pisać w Javie, bo np pracują nad projektem który jest napisany w Javie, a jednocześnie uważają że Java jest językiem syntax-heavy, to znaczy język w dużej mierze opiera się na składni, dla niektórych za dużej. Nie można sobie pozwolić na przepisanie aplikacji na inny język, więc takim "kompromisem" jest dodanie biblioteki (można powiedzieć "meta-programistycznej") które usuwa część składni i zastępuje je deklaratywnym podejściem.
Ja osobiście uważam, że lombok jest średnim rozwiązaniem, bo jeśli już ktoś chce odejść od składni Javy (która, no zgadzam się, jest dość verbose) to należałoby to zrobić w odpowiedni sposób, tzn wydzielić nowy moduł w projekcie, i nowe funkcjonalności pisać w innym jezyku który się kompiluje do JVM byte-code, np Clojure, Kotlin czy Groovy, które mają już przyjemniejszą składnię. I potem czasowo przechodzić z jednego języka w drugi. W mojej opinii lombok to jest taki "pół-środek", i ja wolałbym albo pisać w Javie bez lomboka, a jeśli składnia byłaby zbyt rozwkleła to przemigrowałbym powoli projekt np. na Kotlin.
5
Największym problemem lomboka dla mnie jest to że trzeba pamiętać która adnotacja co robi.
Poprawne wykorzystanie nie jest takie oczywiste.
W nowym projekcie zacząłem czasami korzystać z rekordów i póki co się sprawdzają.
2
Riddle napisał(a):
Ja osobiście uważam, że lombok jest średnim rozwiązaniem, bo jeśli już ktoś chce odejść od składni Javy (która, no zgadzam się, jest dość verbose) to należałoby to zrobić w odpowiedni sposób, tzn wydzielić nowy moduł w projekcie, i nowe funkcjonalności pisać w innym jezyku który się kompiluje do JVM byte-code, np Clojure, Kotlin czy Groovy, które mają już przyjemniejszą składnię
Ale wcale nie trzeba robić takich kombinacji. Bez problemu można zrobić konfigurację gdzie część klas jest napisana w Javie a część już po nowemu w Kotlinie/Scali
3
To ja pójdę w inną stronę. Lombok jest dla mnie nieproduktywny, a wynika to z arytmetyki pracy.
- Lombok zdejmuje z programisty pisanie boilerplate'u, to prawda. Czyli zysk jest jednorazowy.
- Natomiast późniejsza praca z kodem robi się problematyczna. Chcesz zapiąć się debugiem w setterze? No to musisz zmienić kod, lub wyłączyć kompilację przy uruchomieniu debugu. I jedno, i drugie jest uciążliwe. No i jest kwestia jakości pluginów do Lomboka - nie wiem, jak dzisiaj ale swego czasu nie dało się znaleźć wywołania np. lombokowego gettera w Idei.
- Kolejna rzecz to to, że Lombok jest jak granatnik na komendzie policji. Niby taka fajna i niegroźna zabawka, ale wystarczy nacisnąć nie tam, gdzie trzeba.
Według mnie pkt. 2 i 3 przeważają nad pkt. 1. Jeśli chcesz pisać w fajniejszym języku to korzystaj z Kotlina.