Lombok

One of my favourite tools in the Java ecosystem is Lombok. It eliminates boilerplate by automatically generating it at compile-time. This has two important side effects: you cannot make mistakes in this generated code, and generated code keeps up to date with code changes.

These days I usually include this lombok.config configuration file in the root of my projects:

config.stopBubbling = true
lombok.addLombokGeneratedAnnotation = true
lombok.fieldDefaults.defaultPrivate = true
lombok.fieldDefaults.defaultFinal = true
lombok.accessors.chain = true
lombok.accessors.fluent = true

Configuration

When I use setters, I prefer to return the instance I’m working on to be able to chain a lot of calls together. This is set as the default using lombok.accessors.chain = true.

In projects using only immutable data there is no need to do any work in getter methods and thus little use for prefixing getters with get, so by setting lombok.accessors.fluent = true I can omit that everywhere.

[!WARNING] The Accessors features are experimental, and may change in the future.

In business-level immutable code there should be no need to access fields directly so we can set lombok.fieldDefaults.defaultPrivate = true to make everything private unless specified otherwise.

I prefer immutability in my projects, so setting lombok.fieldDefaults.defaultFinal = true sets this as the default, making me do extra work when I have to make fields mutable, and saves a lot of final keywords.

Setting lombok.addLombokGeneratedAnnotation = true helps with some tools that inspect code to indicate that this is generated code.

Lombok can bubble up when searching for configuration. This means that it will traverse up the directories and use the configuration file(s) that it can find. Setting config.stopBubbling = true tells Lombok to stop looking for more files.

@With

Lombok will generate a with method for each field of the type. A with method is like a set method for immutable programming. Instead of mutating a field in-place, it returns a new instance with only the field changed, saving a lot of boilerplate. In JEP 468 a replacement feature could be added in Java itself, although it is not clear yet if this will have an exact overlap with what @With currently provides.

IDE Generation

Code generated by Lombok can also be generated using your IDE. However, an important difference is that code generated by Lombok will keep evolving.

For example, a @Getter on your type will evolve with your type, meaning that when you add or remove fields, it will also add or remove the get methods, which is not the case when you would have generated them using your IDE. This makes code evolution easier.

The same holds for @EqualsAndHashCode. Bugs involving equality can be hard to track down. This can happen when an equals method was not kept up-to-date with changes to fields, or was not aligned with the corresponding hashcode method. Using the Lombok annotation not only makes these bugs impossible but also hides all the implementation details away.

Opinionated

The Lombok library steers you towards a style of programming favouring (among other things) type safe code and immutability. This not only aligns with features from languages like Kotlin and Scala

Java 14 introduced record classes, meaning that we can frequently replace the classes that we would have set up using @Value. For me this highlights the purpose that Lombok fulfils in the Java landscape.