Is it safe to use Project Lombok?

Question

In case you don't know, Project Lombok helps with some of the annoyances of Java with stuff like generating getters and setters with annotations and even simple JavaBean like generation with @Data. It could really help me, especially in 50 different event objects where you have up to 7 different fields that need to be constructed and hidden with getters. I could remove almost a thousand lines of code with this.

However I'm worried that in the long run it will be a regretful decision. Flamewars will erupt in the ##Java Freenode channel when I mention it, providing code snippets will confuse possible helpers, people will complain about missing JavaDoc, and future commiters might just remove it all anyway. I would really enjoy the positive, but I'm worried about the negative.

So: Is it safe to use on any project, small or large? Are the positive effects worth the negatives?

Answer 1

It sounds like you've already decided that Project Lombok gives you significant technical advantages for your proposed new project. (To be clear from the start, I have no particular views on Project Lombok, one way or the other.)

Before you use Project Lombok (or any other game-changing technology) in some project (open source or other wise), you need to make sure that the project stake holders agree to this. This includes the developers, and any important users (e.g. formal or informal sponsors).

You mention this potential issues:

Flamewars will erupt in the ##Java Freenode channel when I mention it,

Easy. Ignore / don't participate in the flamewars, or simply refrain from mentioning Lombok.

providing code snippets will confuse possible helpers,

If the project strategy is to use Lombok, then the possible helpers will need to get used to it.

people will complain about missing JavaDoc,

That is their problem. Nobody in their right mind tries to rigidly apply their organization's source code / documentation rules to third-party open source software. The project team should be free to set project source code / documentation standards that are appropriate to the technology being used.

(FOLLOWUP - The Lombok developers recognize that not generating javadoc comments for synthesized getter and setter methods is an issue. If this is a major problem for your project(s), then one alternative is to create and submit a Lombok patch to address this.)

and future commiters might just remove it all anyway.

That's not on! If the agreed project strategy is to use Lombok, then commiters who gratuitously de-Lombok the code should be chastised, and if necessary have their commit rights withdrawn.

Of course, this assumes that you've got buy-in from the stakeholders ... including the developers. And it assumes that you are prepared to argue your cause, and appropriately handle the inevitable dissenting voices.

Answer 2

Go ahead and use Lombok, you can if necessary "delombok" your code afterwards http://projectlombok.org/features/delombok.html

Answer 3

Personally (and therefore subjectively) I've found that using Lombok makes my code more expressive about what I'm trying to achieve when compared to IDE/own implementations of intricate methods such as hashcode & equals.

When using

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

it's much easier to keep Equals & HashCode consistent and keep track of which fields are evaluated, than any IDE/own implementation. This is especially true when you're still adding / removing fields regularly.

The same goes for the @ToString annotation and its parameters which clearly communicate the desired behavior regarding included / excluded fields, usage of getters or field access and wether or not to call super.toString().

And again by annotating an entire class with @Getter or @Setter(AccessLevel.NONE) (and optionally overriding any divergent methods) it's immediately clear what methods will be available for the fields.

The benefits go on and on..

In my mind it's not about reducing code, but about clearly communicating what you desire to achieve, rather than having to figure it out from Javadoc or implementations. The reduced code just makes it easier to spot any divergent-method implementations.