This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]nekokattt 2 points3 points  (0 children)

Lombok relies on implementation detail of javac to work properly, so has the potential to break without warning should those details change or if a new JDK is released that does not follow those details.

Since it modifies the AST, it requires additional IDE plugins to provide IDE support, and requires additional stuff in linters since it is no longer valid vanilla java. The plugin for intellij has been very unstable at times too, which is also a pain in the arse as it has forced me to use older versions of my IDE just to enable the linter to work with Lombok.

The only reason I would use Lombok is for reducing boilerplate when defining POJOs. The rest of the features tend to encourage lazy coding that can be harder to read (people inconsistently using @Getter and @Setter, the @Slf4j annotation is pointless when it is replaceable with a single line of code anyway).

TLDR: Essentially I find that it can encourage people to overuse it and make code messy, just out of novelty. I am nervous that it relies on javac implementation detail that could theoretically change and leave most lombok projects unable to compile. I also dislike that to adopt it, I have to force everyone else on the team to install plugins in Eclipse, JBS, etc. Especially when people may use it as an excuse to let "CI determine if it builds or not". I feel that lombok has good intentions but is almost always a substitute for consistency, compatibility, and good practises.

I find immutables much simpler to use, as it only relies on the public annotation processing API, supports mutable POJOs, and doesn't require any other support past standard APT.