Why Is Lombok Still in Every Java Developer Toolkit?

Why Lombok still holds its respected place amongst experienced Java developers

Lexica.art

“Why are you using Lombok to generate getters and setters? I prefer to write them on my own.” — says my coworker and merges the boilerplate getters into the codebase.

Why are developers against Lombok? What are the wrong beliefs they have about Lombok? And why do they prefer to write the boilerplate on their own?

Any tool is deadly if used wrong. One such tool is Lombok. Simple annotation can backfire and cause weird bugs. And this happens only if one abuses Lombok, otherwise it’s a great tool.

Here are some of the misbeliefs I’ve heard about Lombok.

You can trick the compiler using Lombok

@SneakyThrows circumvents the need to handle the checked exception. It’s impossible to have the handlers written without a lot of boilerplate.

This is a hack and trick for the compiler. There’s no counterargument.

Do we really sacrifice so much using this hack? I wouldn’t say so.

With proper error handling up in the call stack, you won’t feel this hack. And on the backend, you get a more readable code that’s…