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.

Peeking into the future

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 final var.

So much code, yet no value

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 @Getter, @Setter and @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 @Getter, @Setter, @ToString, @EqualsAndHashCode, and @RequiredArgsConstructor.

@Value - Immutable variant of @Data

@Slf4j - Adds private static final Logger log

@ToString - Generates a human-readable toString method

@EqualsAndHashCode - Generates hashCode and equals based on the fields in your object

Not all roses and sunshine

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.