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.
this post was submitted on 09 Apr 2025
8 points (75.0% liked)
Java
1622 readers
14 users here now
For discussing Java, the JVM, languages that run on the JVM, and other related technologies.
founded 2 years ago
MODERATORS
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
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)
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
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.