Komentarze do: Lombok dobre i słabe strony

Autor: Mateusz Dąbrowski

Mateusz Dąbrowski — Thu, 23 Mar 2023 11:17:56 +0000

W odpowiedzi do adam.

Dobra kończę, bo pewnie pierdziele głupoty o 2 nad ranem

Trochę tak ;) a trochę masz rację, ale problemy, które opisałeś, są w większości nieistotne albo do rozwiązania w łatwy sposób. Zachęcam do zapoznania się z dokumentacją. Większość ludzi używa Lomboka, zwłaszcza jak korzystają ze Springa i Spring Data (bo jest już dołączony w tej paczce). Skraca on czas pisania kodu i to jest bardzo istotna zaleta ;)

Autor: adam

adam — Thu, 23 Mar 2023 00:59:21 +0000

Ja tej biblioteki nie używałem, ten wpis był pierwszym miejscem gdy zapoznałem się z nią, ale już widzę kilka problemów, nie wiem czy dobrze zrozumiałem zasadę działania, ale jeśli tak to kod jest budowany w procesie kompilacji zgodnie z annotations. Czyli jak na klasie postawie adnotacje do setterów i getterów to wygeneruje mi je dla wszystkich zmiennych, ale mogę mieć przecież zmienne prywatne określające stan obiektu i o ile getter byłby przydatny o tyle setter już niekoniecznie. Poza tym w tym getterze lub setterze mogłyby być robione jeszcze jakieś dodatkowe operacje i już to jest niemożliwe. To samo z konstrukorami. Konstruktor konstruuje obiekt, nie tylko ustawia jego membery. W takich sytuacjach jest to nieprzydatne. Kolejna sprawa to czas kompilacji. Kolejna to dodawanie do projektu dodatkowej biblioteki, która zasadniczo nie wnosi nic poza tym oczyszczeniem kodu to ryzykowna zabawa, bo zyskuje się niewiele (jak dla mnie to nic), a ryzykuje błędami które może mieć ta biblioteka i na dodatek może potem być problem z nazwami adnotacji z innych bibliotek czy frameworków, właściwie nie wiem czy w adnotacjach w Javie można rozwiązać konflikty nazw, jeśli można no ten ten problem odpada, ale chyba nie można, w każdym razie nie wiem tego. Pewnie jakbym zapoznał się z tym bliżej i przemyślał temat to znalazłbym więcej wad. Nie wiem jak wygląda sprawa z debuggerem :). Dobra kończę, bo pewnie pierdziele głupoty o 2 nad ranem 🙂

Autor: Adam

Adam — Fri, 30 Dec 2022 15:37:14 +0000

To może nie wada, ale ostatnio znalazłem błąd, który był małoczytelny w Lomboku
import javax.ws.rs.QueryParam + BeanParam -z pomocą tych 2 adnotacji można stworzyć BeanParam który zmapuje wszystkie queryParamy. W ramach refactoru dodaliśmy tą adnotację do klasy która wcześniej miała adnotację @Builder z lomboka.
Builder wykluczał bezargumentowy kontstruktor i błąd był bardzo nieczytelny. To nie wada Lomboka, ale trzeba pamiętać że Builder będzie się kłócił z wstrzykiwaniem QueryParam czy JPA, może by mogli czytelniejszy wyjątek dodać

Autor: czesio

czesio — Mon, 14 Oct 2019 12:24:32 +0000

Przy okazji warto zwrócić uwagę też uwagę na @ToString na encji, które może wykonać wywołanie pól opisanych adnotacją @LazyLoad.

Autor: Mateusz Dąbrowski

Mateusz Dąbrowski — Tue, 13 Aug 2019 12:06:48 +0000

W odpowiedzi do Marek.

Dzięki za komentarz Marek.
Ad. 1 i 2 Zgadza się może nie napisałem tego wystarczająco jasno, ale o to właśnie chodzi.
Ad. 3 Trafna uwaga

Autor: Marek

Marek — Tue, 13 Aug 2019 11:59:23 +0000

1. Koniecznosc uzycia NoArgsConstructor dla encji hibernetowych – to problem samego hibernata , a nie lomboka samego w sobie. Ma byc konstruktor i kropka. To samo za
2. Immutable class i NoArgsConstructor -> to specyfka javy i final, a nie problem lomboka

Poza tym wszystko sie zgadza. Dodalbym jeszcze:
3. koniecznosc wlaczenia „annotation processing” w Intelij albo „org.projectlombok:lombok:${lombokVer}” w gradle

Pozdawiam

Autor: Punky

Punky — Fri, 09 Aug 2019 04:27:26 +0000

W odpowiedzi do Marcin. Tak jak sugerował kolega wyżej… Lombok może być etapem pośrednim zanim przesiądziemy się na Kotlina ? tak było w moim wypadku. Nic tak dobrze nie eliminuje boilerplate jak Kotlin i tyle ?

Autor: Marcin

Marcin — Thu, 08 Aug 2019 15:58:00 +0000

W odpowiedzi do Mateusz Dąbrowski. Co do samych zalet używania Lomboka zgadzam się w pełni i całkiem fajny artykół, ale wydaje mi się że ludzie powinni wiedzieć w co się pakują zanim zaczną używać lomboka ;) A co do zmiany jezyka to wiem że często to jest problem, ale dorzucanie stopniowo do projektu Kotlina jest storunkowo proste (nikt nie mówi o rewolucji i przepisywaniu projektu), najwiekszym problemem jest przekonanie zespołu.

Autor: Mateusz Dąbrowski

Mateusz Dąbrowski — Thu, 08 Aug 2019 12:36:06 +0000

W odpowiedzi do Marcin.

Dzięki za komentarz Marcin. Masz rację, ale bez tego haka nie było by Lomboka. Ja starałem się wypisać głównie wady związane z użytkowaniem tego narzędzia.

Co do przyszłości Lomboka, to myślę, że nie ma się o co martwić. Jeśli wystarczająco duża ilość developerów będzie go używać, to będzie bezpieczny.

Niech przykładem będzie klasa Unsafe, której używanie to też hak. A kiedy developerzy Javy chcieli ją usunąć, społeczność zaprotestowała i klasa ta nie została usunięta.

Co do innych języków, w większości przypadków nie jest to opcja. Zwykle nie możesz tak po prostu zmienić języka w projekcie.

Autor: Marcin

Marcin — Thu, 08 Aug 2019 09:00:42 +0000

Brakuje mi tylko w minusach lomboka ze jego mechanizm działania jest oparty na jednym wielkim hacku i bazuje na nie dokonać oficjalnym api kompilatora którego raczej nie powinno się używać i które w kolejnych wersjach javy może zniknąć co może skutecznie uniemożliwić upgrade javy w naszym projekcie.
Uważam ze jezeli tak bardzo przeszkadza nam ten zbędny kod w Javie to już lepiej zacząć korzystać z języka który oferuje nam takie ułatwienia jak Kotlin/Scala