5 Tips For Using Lombok In Production

I was reminded the other day about the excellent Project Lombok. If you're not familiar with this tool, it helps reduce boilerplate AND testing. You annotate your Java source code with some special annotations, and it generates code for you. For example, if you annotate a field with a @Getter, it generates a public getter method for that field.

Having previously used it successfully on a number of production systems, here are my top five tips.

Tip 1: No Lombok With Logic

Bytecode compiled for generated code is hard to debug. This is made more confusing where generated code gets mixed with logic. Lombok works well if you don't mix it with logic.

A useful side effect of this tip is that classes only contain generated code.

Tip 2: Don't Test the Generated Code

The generated code is trustworthy, so you can save a lot of time by not testing it or performing static analysis on it.

If a class only contains fields, then you don't need to test it or perform static analysis on it.

Tip 3: Use @Data for Your DAOs

Where is Lombok especially useful then? In DAOs. These objects typically don't have a lot of logic and carry a great deal of boilerplate. Specifically, three annotations were the most useful, two of which we'll get to in the next sections.

@Data creates your getters, setters, to string, and equals/hashcode. Great for DAOs in either the database layer or the API layer.

Tip 4: Use @Value for Immutable Value Objects

@Value is essentially an immutable version of @Data. Very useful for immutable value objects. Use in many of the cases you might use a Scala case class.

Tip 5: Use @Builder

@Builder is useful when you have an object with many fields with the same type. Rather than having a constructor with many string fields, use the builder instead.

Tip 6: Think About Avoiding the Other Annotations

There are a number of annotations that we never found widely useful:

• val: A great idea, but hobbled by poor IDE support.
• @Cleanup: Use try-with-resources.
• @SneakyThrows: Throw only runtime exceptions, and perform exception mapping where needed.
• @Synchronized: Just never found a place to use this.

Tip 7: Exclude Generated Classes From Sonar Reports

As the generated code typically ends up with many untested methods (e.g. you never test the generated equals, as you don't need to, but they tend to end up being very complex for classes with many fields), these classes are excluded for static analysis and code coverage. If you are using Maven and Sonar, you can do this using the sonar.exclusions property.