Should you use Lombok with logic? Which annotations are the most useful? Which aren’t? See how can you make the most out of Lombok in production code.
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.
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.
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.
@Data creates your getters, setters, to string, and equals/hashcode. Great for DAOs in either the database layer or the API layer.
@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.
@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.
There are a number of annotations that we never found widely useful:
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.
