Want to use the
var keyword, but your team is stuck on Java 8? Lombok can help you. Sick and tired of writing and maintaining getters and setters? Lombok can help you.
2 min read
By Nicklas Utgaard
December 7, 2019
Project Lombok is a Java compile-time library that “extends” the Java-experience by adding new and exciting annotations and keywords. It does this by utilizing JSR 269: Pluggable Annotation Processing API and a myriad of other internal and/or compiler-specific APIs.
While some projects may be using Java 11 or 13, there is still a lot of developers and code stuck in the pre- Java-9 era. Project Lombok might help you to peek into the future if this is your everyday reality.
Java 10 introduces the
var keyword, extending the usage of type inference to include your everyday variables. In term of code this means that the previously verbose
Customer customer = new Customer("Frank");, can be simplified to
var customer = new Customer("Frank");. Add Project Lombok to your built tool and you may experience this glorious new-found freedom yourself, even if you're stuck at Java 8. As a treat, Project Lombok even adds
val, which is similar to Java 10's
Writing and maintaining a decent sized domain-object can be extremely tedious. Update a field name, and you better make sure you update your getters and setters. Perhaps your team likes using the builder-pattern, adding even more required maintenance. Project Lombok's remedy; add
@Builder to you domain class, and you're good.
Project Lombok introduces a whole set of interesting annotations to use. Some of the ones I've used the most are:
@Data - Shortcut for
@Value - Immutable variant of
@Slf4j - Adds
private static final Logger log
@ToString - Generates a human-readable
@EqualsAndHashCode - Generates
equals based on the fields in your object
While Project Lombok undoubtedly has some nice features, it also comes with a cost and risks.
In order for your team to be productive they must all install an IDE plugin. Most major IDEs are supported.
The usage of non-standard/internal APIs, and how this may affect the future of the codebase.
Other alternatives may also be better suited for your team, e.g; upgrading to a newer version of Java, or introducing Kotlin if you main concern is reducing boilerplate code.