4 ms·

It's not 80 lines. It's many thousands of lines in any real project. Lines that you should keep synchronised with "source of truth". People love Lombok for a re

It's not 80 lines. It's many thousands of lines in any real project. Lines that you should keep synchronised with "source of truth". People love Lombok for a reason. And most developers don't really care about implementation details, they believe that Lombok is "big enough" to work in the foreseeable future. It worked for them for years, it's supported well in Idea. I, personally, avoid Lombok, specifically because I care about implementation details. Because if I would have wanted better Java, I'd go with Kotlin rather than this hacky way of using another Java-like language. But other people hold different opinions.

cogman10 2y ago
There are alternatives that don't rely on jvm internals to accomplish their goals. They do like 90% of what lombok does. Immutables and AutoValue are two examples I've used that work fine. The 10% lombok can do because it's peaking at internals isn't valuable. I don't, for example, need an annotation to create a static logger. That's dumb.
ivan_gammel 2y ago
For me personally those thousands of lines are often garbage. For example, constructors and fields generated by Lombok do not validate inputs, yet failing early instead of deferring the problem to client code reading the value is the easiest way to fight bugs. Sometimes one business method setting several values instead of multiple getters is better or the only possible way to preserve integrity of the state. Sometimes a field reflecting internal state will be annotated to produce getter and thus breaking the encapsulation. With all of that Lombok encourages poor code quality by enabling developers being lazy.
xxs 2y ago
>It's many thousands of lines in any real project. I dont use lombok and the latter has been actively removed. If you have access to records, lombok is just bad. Even if you dont have - public final fields are sufficient in most case + c-tor and validation there. Just dont use getters & setters.

cogman10 2y ago

There are alternatives that don't rely on jvm internals to accomplish their goals. They do like 90% of what lombok does. Immutables and AutoValue are two examples I've used that work fine. The 10% lombok can do because it's peaking at internals isn't valuable. I don't, for example, need an annotation to create a static logger. That's dumb.

ivan_gammel 2y ago

For me personally those thousands of lines are often garbage. For example, constructors and fields generated by Lombok do not validate inputs, yet failing early instead of deferring the problem to client code reading the value is the easiest way to fight bugs. Sometimes one business method setting several values instead of multiple getters is better or the only possible way to preserve integrity of the state. Sometimes a field reflecting internal state will be annotated to produce getter and thus breaking the encapsulation. With all of that Lombok encourages poor code quality by enabling developers being lazy.

xxs 2y ago

>It's many thousands of lines in any real project. I dont use lombok and the latter has been actively removed. If you have access to records, lombok is just bad. Even if you dont have - public final fields are sufficient in most case + c-tor and validation there. Just dont use getters & setters.