The original post if you don't want to go through LinkedIn https://dev.to/yanev/why-i-believe-lombok-should-be-discarded-from-java-projects-1g4h
this post was submitted on 09 Apr 2025
7 points (73.3% liked)
Java
1703 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
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)
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.
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 personally switched from Java + Lombok to Kotlin. So Lombok isn't really needed anymore.
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.
Its just leaner:)
I disagree. It looks leaner. But the code is still there and because it's invisible, it requires you to remember more.