8
submitted 1 week ago* (last edited 1 week ago) by Custodian6718@programming.dev to c/java@programming.dev

Java champions and Senior engineers speaking out against lombok

top 8 comments
sorted by: hot top controversial new old
[-] Lysergid@lemmy.ml 6 points 1 week ago

Never had an issue with Lombok. Though I use only getters, setters, constructor and sneaky throws. And I don’t know what exactly they want to debug. It’s literally assignments in most cases. According to such logic, should all reflection based tool be removed too? I guess remove “bad” Spring and JPA/Hinernate then? What a nonsense

[-] Von_Broheim@programming.dev 1 points 4 days ago* (last edited 4 days ago)

I thought that the whole point of Lombok is that it's not reflection based, they explicitly refuse to use reflection as a design principle. Afaik lombok statically generates methods and classes at pre compile. That's why for example lombok does not support constructor inheritance or overloading.

[-] BlackEco@lemmy.blackeco.com 6 points 1 week ago
[-] Custodian6718@programming.dev 1 points 1 week ago* (last edited 1 week ago)

thanks for extracting the original post. i only put the linkedin as a source because you can clearly see java champions on social media speaking out against lombok (which you obviously cant on the original post)

[-] McMonster@programming.dev 3 points 1 week ago

Anything that does under-the-cover low level magic is bad. The deeper the magic, the worse. Spring is the particular offender here with the lengths it goes so to make you not use new and never be able to debug why something happens. Or worse, why something doesn't happen. We know how to deal with code, but not magic.

[-] Von_Broheim@programming.dev 1 points 4 days ago

There's no magic in lombok, they're just meta annotations for class generation, no different than having each end every class implement some very specific interface exactly the same way every time. It's for reducing copy pasting. Debugging it is not a problem, especially that you can see the generated classes in the library files. Spring on the other hand is a black box, because it does too much and has become very bloated over the years, the goal of Spring is not to avoid using new the point is simplifying dependency injection and composition. The most fried part is the transaction management imo, because it's too delicate in the way it has to be configured.

I never saw a benefit in using Lombok, but I did run into issues with it. As it works outside the compiler, you are basically writing Java+Lombok. And as the article says, with an IDE and a recent JDK there is really no benefit provided by Lombok.

[-] glorkon@lemmy.world 2 points 1 week ago

I personally switched from Java + Lombok to Kotlin. So Lombok isn't really needed anymore.

this post was submitted on 09 Apr 2025
8 points (75.0% liked)

Java

1637 readers
1 users here now

For discussing Java, the JVM, languages that run on the JVM, and other related technologies.

founded 2 years ago
MODERATORS