Lombok w 2024 roku

Używacie jeszcze Lomboka w 2024 roku? Mam mieszanie uczucia do niego. Z jednej strony faktycznie trochę tego boilerplatu usuwa ale z drugiej strony ma kilka problemów, np. nie mogę zobaczyć gdzie jest używany konstruktor danej klasy itp.

Nie używam do nowego kodu od lat, tam gdzie się da - usuwam.

Może i ułatwia pisanie kodu, ale utrudnia jego utrzymywanie - chcę mieć widoczny kod który się rzeczywiście odpala, nie dyrektywy preprocesora w stylu C.

Często do DTO używam. Fakt, są z nim swoje problemy, jednak ogólnie te rzeczy nie zmianiają za bardzo pracy ani mi nie przeszkadzają.

Nofenak napisał(a):

, np. nie mogę zobaczyć gdzie jest używany konstruktor danej klasy itp.

Można np ctrl + shift + f i wyszukać new ClassName itp itd

Pinek napisał(a):

Często do DTO używam. Fakt, są z nim swoje problemy, jednak ogólnie te rzeczy nie zmianiają za bardzo pracy ani mi nie przeszkadzają.

A do DTO nie starczą rekordy?

benoni12 napisał(a):

A do DTO nie starczą rekordy?

Starczą, niemniej skoro już są klasy z lombokiem to nie widzę różnicy czy to record czy klasa z lombokiem xd
Poza tym czasami rekordy gryzą się z jacksonem i są hocki-klocki z serializacją.
Serio, takie szczegóły to ważne są w rozmowie kwalifikacyjnej, ale podczas codziennego programowania odpowiada to za bardzo mały procent.

Nofenak napisał(a):

Używacie jeszcze Lomboka w 2024 roku? Mam mieszanie uczucia do niego. Z jednej strony faktycznie trochę tego boilerplatu usuwa ale z drugiej strony ma kilka problemów, np. nie mogę zobaczyć gdzie jest używany konstruktor danej klasy itp.

Ależ łatwo możesz to zobaczyć: opt + F7 i przechodzisz do new instance creation czy cos takiego. A odpowiadając na Twoje pytanie - tak, używam. Nie miałem jeszcze przypadku kiedy przez niego klnąłem itp. Przyspiesza pracę, jak dla mnie więcej zalet niż wad :) Jakieś jeszcze inne problemy masz z lombokiem?

lombok w 2024 to sabotaż. Czemu nie używać klas z finalnymi publicznymi polami lub rekordów, bo to pokrywa jakieś 95% zastosowań?

Dokładnie.
Używanie do getterów, setterów i konstruktorów nie ma już sensu a używanie do czegoś bardziej skomplikowanego jak buildery etc wprowadza tylko zamieszanie - nie wiem jaki kod jest wykonywany dopóki nie poznam składni kodu generowanego przez daną adnotację Lomboka.

Ale może jestem spaczony, ja od zawsze traktowałem Lomboka jako narzędzie do prototypowania, a nie do używania w kodzie produkcyjnym.

opiszon napisał(a):

używanie do czegoś bardziej skomplikowanego jak buildery etc wprowadza tylko zamieszanie

Ja właśnie najbardziej lubię lombokowe @Builder - spoko wtedy się robi jednolinijkowce, po prostu tak mi wygodnie xD

W poprzedniej firmie przeszliśmy na kotlina i lombok zniknął
W prywatnych projektach nie używam.
Obecnie w kodzie legacy mam tego trochę, ale robię refaktor i gdzie się tylko da to usuwam.
Czasem zostawię @Getter, ale konstruktory generuje mi IDE

Lombok ma jedną wadę. Nie jest nią to, co robi, bo generatorów kodu na podstawie adnotacji jest mnóstwo, a rozwiązani takie jak Quarkus tylko zyskują na popularności, ale sposób, w jaki to robi. Lombok to jeden wielki i paskudny hak korzystający z wewnętrznych API kompilatora. Przez co nigdy tak naprawdę nie wiadomo, czy efekt jego działania będzie dobry, czy zły.

Lombok to teraz antypattern. Masz rekordy.

@Korges masz JPA. Użyj rekordów jako encji JPA bez hakowania w stylu cała encja jako Embedded :D

Jak ktos pracuje z legacy to lombok to wybawienie. Od 17stki w gore raczej powoli bym odchodzil.

Nie lubiłem lomboka, ale ostatnio trafiałem do projektów, gdzie lombok był obecny i z czasem go polubiłem. Doceniam wygodę jaką za sobą niesie, oczywiście pod warunkiem minimalnego korzystania z adnotacji, zamiast wrzucania wszystkich, które się da, na zapas.

Używam i używać będę bo record Point(int x, int y) { } jest w Javie zje****y - brakuje mianowicie metody toBuilder() lub jakieś copyWith(x = 7).

Takie rzeczy są i w Scala:

case class Message(sender: String, recipient: String, body: String)
val message4 = Message("[email protected]", "[email protected]", "Me zo o komz gant ma amezeg")
val message5 = message4.copy(sender = message4.recipient, recipient = "[email protected]")
message5.sender  // [email protected]
message5.recipient // [email protected]
message5.body  // "Me zo o komz gant ma amezeg"

oraz w C#:

public record Person(string FirstName, string LastName)
{
    public string[] PhoneNumbers { get; init; }
}

public static void Main()
{
    Person person1 = new("Nancy", "Davolio") { PhoneNumbers = new string[1] };

    Person person2 = person1 with { FirstName = "John" };
    Console.WriteLine(person2);
    // output: Person { FirstName = John, LastName = Davolio, PhoneNumbers = System.String[] }
    Console.WriteLine(person1 == person2); // output: False

Niestety w Javie musi być record niedorobiony, niedopracowany i niedopieszczony.

Tak długo jak taki rekrod będzie, tak długo Lombok będzie w użyciu.

@99xmarcin to nie jest kwestia rekordu, ale tego, że w Javie, a w zasadzie JVM, nie masz informacji o nazwach parametrów. Scala też nie ma parametrów nazwanych, jako takich, ale nadrabia to za pomocą metadanych i różnych sztuczek, które wykonuje kompilator. Zatem to nie problem „niedorobionych” rekordów.

@Koziołek kompilator to taki gość który może sobie wygenerować tyle dodatkowego kodu ile mu potrzeba, na przykład mógłby zmienić kod:

record Point(int x, int y) { }
var p = new Point(3, 45);
var p2 = p.copyWith(x = 45)

na

var p = new Point(3, 45);
var p2 = p.withX(45)

czyli może i nazw parameterów by nie było, ale każdy parametr miałby też metodę "with'era" czyli Point withX(int newValue) która zwracała by kopię obiektu.

Alternatywna opcja to po prostu dodanie adnotacji z nazwami parametrów, tak jak się to dzieje obecnie gdy użyjemy flagi -parameters dla javac.

Wprowadzenia niedorobionych cech języka gdy można to załatać na poziomie bytecode'u to nie jest dobry design...

PS. Ten JEP (https://openjdk.org/jeps/468) potwierdza to co wielu z nas czuje używając rekordu - czegoś nam tu brakuje! Dokładnie buildera lub withera lub jak zwał tak zwał, ale możliwości update'u na obiekcie który ma 10 pól bez konieczności przepisywania ich wszystkich!

@99xmarcin a powiedz ty mi skąd ten biedny javac ma wiedzieć co ty masz na myśli pisząc coś takiego:

var p2 = p.copyWith(x = 45)

Czy ty przypisujesz coś, czy ten x to nazwa dostępna w kompilacji, a jak jest z zewnętrznej biblioteki, to skąd mam wiedzieć, że ten x to na pewno x, a nie y. Scala zrobi to sobie za pomocą wygenerowania dodatkowych metod. Java ma trochę inne założenie. Nie może wygenerować nic, czego nie ma jawnie w kodzie (z wyjątkiem konstruktora bezparametrowego, jeżeli nie ma innych). To jest zupełnie inna filozofia języka.

są szkice pomysłów na to jak do javy dodać coś a'la scalowe .copy( czy c#owe with: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md

p.s.
aaa, sorry, zostało już wspomniane:

99xmarcin napisał(a):

PS. Ten JEP (https://openjdk.org/jeps/468) potwierdza to co wielu z nas czuje używając rekordu - czegoś nam tu brakuje! Dokładnie buildera lub withera lub jak zwał tak zwał, ale możliwości update'u na obiekcie który ma 10 pól bez konieczności przepisywania ich wszystkich!

sorry za offtop: może się czepiam, a może to niefortunny dobór przykładu w JEPie, tylko jak ktoś jako przykład wybiera dzielenie przez zero i od razu przerywa pracę programu, to ja nie wiem co myśleć.
Jaka stoi za tym filozofia? Ok, mamy propozycję poprawki, zilustrujemy to w najgorszy możliwy sposób