Why I avoid Lombok in my projects

Personal thoughts, not a source of truth 😉

I meet Lombok some years ago, at the beginning, it looked interesting and I tried using it in a project, after some lines of code I started to feel the resulting code just weird, I was not sure why it bothers me that much then I stopped using it and I have tried to avoid it since.

Usually, my instinct tells me stuff that I don't understand completely so, what I do? I read to try to understand what my instinct was saying then, I started reading articles about "Why not to use Lombok" and I saw many reasons like:

Lombok modifies the bytecode.

Lombok is a "hacky" way of using a spec.

The security level in java is changing constantly and eventually, the "hack" that Lombok uses will disappear.

Sometimes weird errors in Runtime appears and they are hard to find.

Debug is hard because the bytecode that is running is different from your code.

But even with this, I was not satisfied, the reason why Lombok bothers me was not on this list, then I said to myself "let's follow my instincts, don't use it and with the time it will come".

Years have passed, a lot of NPE in my life have modeled my way of thinking and coding but I was still asking myself "why does Lombok bother me?", until some weeks ago in my meditation temple (the shower 🚿) when these sentences came to my mind "Lombok hides design errors".

Why Lombok hides design errors

Let's think about some of the most used Lombok annotations to explain why I think this.

@Data

This annotation is awesome, you don't have to be writing getters, setters, toString, equals nor hashCode methods, then you just add the fields you need in your class and everything is autogenerated so you don't have to expend time with those verbose methods.

Till here everything is cool, our class contains just attributes with a lot of methods we don't see and that looks pretty but, here is where Lombok "hides the errors" in the fact that we see a thin class so we don't ask "does this class have not more responsibilities that it should?" but, why we don't ask this? because the class looks pretty, awesome, beautiful, 😍, but when we cannot use Lombok we just see a class that looks ugly, huge, 🤢 and immediately we think how to solve this via design.

@AllArgsConstructors

Similar here, we don't see that huge constructor and we add dependencies to our class like crazy without asking "isn't this class doing more than it should?", usually, a huge constructor tells us this, but if we don't see it, we won't figure that out.

@Builder

Same, Do we really need a builder for this class? Why do we need a builder? Why this class is so big that we want a builder to simplify its instantiation?

Conclusions

Lombok is very powerful but as Uncle Ben says "With great power comes great responsibility".

I know that you can think "This is a developer problem that can happen with or without Lombok" and this is true, but when you or other team members see that ugly code someone will try to make it better.

But as some people say "If I don't see it, it's not there". Like the wall in my office, if I don't see those holes, they are not there 😅.