I know about Lombok since a long time, and I even wrote on how to create a new (at the time)
@Delegate annotation. Despite this and even though I think it’s a great library, I’ve never used it in my projects. The reason for this mostly because I consider setting up the Lombok agent across various IDEs and build tools too complex for my own taste in standard development teams.
Comes Kotlin which has support for IDEs and build tools right out-of-the-box plus seamless Java interoperability. So, I was wondering whether Lombok would still be relevant. In this article, I’ll check if Kotlin offers the same feature as Lombok and how. My goal is not to downplay Lombok’s features in a any way, but to perform some fact-checking to let you decide what’s the right tool for you.
The following assumes readers are familiar with Lombok’s features.
Kotlin types can be either nullable i.e.
No equivalent as class and constructor declaration are merged
Takes advantage of merging class and constructor declaration with slightly different semantics
No equivalent but pretty unusual to just have a setter (does not favor immutability)
No direct equivalent but included in
Notice the difference between
No direct equivalent, but possible in many different ways
There’s no such thing as checked exceptions in Kotlin. Using Java checked exceptions requires no specific handling.
No direct equivalent, use named arguments instead.
It’s possible to omit to reference an object in the annotation: Lombok will create one under the hood (and use it).
No direct equivalent, available through
Available in many different flavors
- Lombok offers some more features
- Lombok offers some more configuration options, but most don’t make sense taken separately (e.g.
- Lombok and Kotlin have slightly different semantics when a feature is common so double-check if you’re a Lombok user willing to migrate
Of course, this post completely left out Kotlin’s original features. This is a subject left out for future articles.