5 Tips For Using Lombok In Production
5 Tips For Using Lombok In Production
This look at using Lombok to reduce boilerplate code in production examines useful annotations and a few general practices to keep in mind.
Join the DZone community and get the full member experience.
Join For FreeBuild vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!
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.
Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.
Like This Article? Read More From DZone
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}