avatarEmanuel Trandafir

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

2413

Abstract

ure id="d883"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*stlElRVa0muGp1TkRH4pBw.png"><figcaption></figcaption></figure><p id="c37c">As we can see, for classes with large numbers of attributes, Lombok’s builder or <a href="https://readmedium.com/you-might-stop-using-lomboks-builder-after-reading-this-9139c22e75a7">fluent setters <i>(if the class is not immutable)</i></a><i> </i>will lead to clear and direct code. This is especially useful when we need to manually instantiate the objects.</p><p id="95ca">On the other hand, for objects that will automatically be created by other libraries or frameworks, records can still be a good shout —<i> for instance, we can imagine deserialization (ex: jackson), automatic mapping (ex: mapstruct)… etc.</i></p><p id="c399"><b>So, records are a good option as long as we don’t need to manually use the long and ugly constructor with loads of arguments.</b></p><h2 id="e2ca">3. Using Records and Lombok Together</h2><p id="4c18">Sticking to the <i>@Builder</i> annotation from the previous section, we have to mention that it integrates nicely with the new record type.</p><p id="295d">In other words, we can annotate a record with <i>@Builder,</i> and Lombok will implement the builder design pattern and allow us to use it when instantiating the object.</p><figure id="74e1"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*w7IF22qN64gx128EDwGv_Q.png"><figcaption></figcaption></figure><p id="b35a">Moreover, Lombok's <i>@With</i> annotation also works with records. <i>@With </i>is the immutable object equivalent for <i>@Setters </i>and it will always return a new instance of the object:</p><figure id="fdd6"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*xgNa1KUwYzOHzMneWzMyUg.png"><figcaption></figcaption></figure><p id="72c4">With the arrival of the <i>record </i>type, the usage of <i>@With </i>and <i>@Builder </i>might actually grow in popularity, showing that records and Lombok can live and work together.</p><figure id="8f69"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*T4RoxkMx1ZZSkgkdHWIfeQ.png"><figcaption></figcaption></figure><h2 id="f688">4. Mutable Data</h2><p id="3951">Even if we adopt a functional or reactive style of programming, we might still want to allow some classes to mutate state.</p><p id="7f75">This can be either because of design considerations or b

Options

ecause of frameworks or libraries that are relying on it — for instance, configuration classes and JPA @Entities.</p><p id="a657">For all of these mutable objects, we can still use Lombok to avoid writing boilerplate code.</p><h2 id="60fc">5. Other Lombok Annotations</h2><p id="dd78">Lombok isn’t only about <i>getters </i>and <i>setters. </i>Let’s not forget other useful features it offers, such as various types of constructors, <i>@SneakyThrows</i>, <i>@Slf4j, @NonNull, </i>and many others.</p><p id="673f">For instance, my favorite feature of Lombok is <i>@RequiredArgConstructor</i> which plays nicely with Spring’s constructor dependency injection.</p><h2 id="2506">6. Conclusion</h2><p id="a9a5">I know, I know. This might not be the answer you all wanted, but we just cannot simply replace Lombok with <i>records</i>.</p><p id="7d74">There’s a lot of hatred against Lombok, probably caused by its abusive and inappropriate usage.</p><p id="ea5c">Though, we have to admit that, if it is used properly it can be a great tool. We can enforce this through good coding practices, pair programming, and attentive code reviews.</p><p id="156d">As a wise man once said, when he initially found out about Lombok:</p><p id="2210" type="7">“With great power, comes great responsability“</p><p id="3bb9" type="7">— Spiderman, web developer</p><figure id="f1b0"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*BqxTK8Xfk0c7YntP"><figcaption>Photo by <a href="https://unsplash.com/@rubensukatendel?utm_source=medium&amp;utm_medium=referral">Ruben Sukatendel</a> on <a href="https://unsplash.com?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h1 id="10ca">Thank You!</h1><p id="fa0a">Thanks for reading the article and please let me know what you think! Any feedback is welcome.</p><p id="2bb4">If you want to read more about clean code, design, unit testing, functional programming, and many others, make sure to check out <a href="https://readmedium.com/start-here-6d2b065a626">my other articles</a>.</p><p id="30b7">If you like my content, consider <a href="https://medium.com/@emanueltrandafir">following or subscribing</a> to the email list.</p><p id="e866">Finally, if you consider becoming a Medium member and supporting my blog, here’s my <a href="https://medium.com/@emanueltrandafir/membership">referral</a>.</p><p id="ddb2">Happy Coding!</p></article></body>

Records Are Here! Can We Remove Lombok Already?

In this article, we’ll discuss Java 17’s records and see if we can leverage the new keyword to completely replace the usage of Lombok.

image generated on imgflip.com

1. Records vs Lombok’s @Value

Lombok offers the @Value annotation to help us generate immutable “value objects”. Even though this can come in handy in some situations, I rarely saw this feature used.

For instance, the following code snippet will generate an immutable FullName class:

Though, we can further simplify this declaration by using Java 17’s new feature, the record keyword:

The two solutions will have the same result. In this case, it will be simpler to use the language feature rather than some external library.

image generated on imgflip.com

So, if you only use Lombok for small, immutable objects — yes, you can remove it. Though, this is probably not the case. Let’s continue with other places where we might want to keep using Lombok.

2. Record vs Lombok’s @Builder

We can use Lombok’s @Builder annotation to create objects with a large number of attributes.

Also, the builder design pattern can be very useful if some of the parameters are optional, making the creation of the object easier to understand.

Let’s see how we can create an account instance declared as a record compared to Lombok’s @Builder:

As we can see, for classes with large numbers of attributes, Lombok’s builder or fluent setters (if the class is not immutable) will lead to clear and direct code. This is especially useful when we need to manually instantiate the objects.

On the other hand, for objects that will automatically be created by other libraries or frameworks, records can still be a good shout — for instance, we can imagine deserialization (ex: jackson), automatic mapping (ex: mapstruct)… etc.

So, records are a good option as long as we don’t need to manually use the long and ugly constructor with loads of arguments.

3. Using Records and Lombok Together

Sticking to the @Builder annotation from the previous section, we have to mention that it integrates nicely with the new record type.

In other words, we can annotate a record with @Builder, and Lombok will implement the builder design pattern and allow us to use it when instantiating the object.

Moreover, Lombok's @With annotation also works with records. @With is the immutable object equivalent for @Setters and it will always return a new instance of the object:

With the arrival of the record type, the usage of @With and @Builder might actually grow in popularity, showing that records and Lombok can live and work together.

4. Mutable Data

Even if we adopt a functional or reactive style of programming, we might still want to allow some classes to mutate state.

This can be either because of design considerations or because of frameworks or libraries that are relying on it — for instance, configuration classes and JPA @Entities.

For all of these mutable objects, we can still use Lombok to avoid writing boilerplate code.

5. Other Lombok Annotations

Lombok isn’t only about getters and setters. Let’s not forget other useful features it offers, such as various types of constructors, @SneakyThrows, @Slf4j, @NonNull, and many others.

For instance, my favorite feature of Lombok is @RequiredArgConstructor which plays nicely with Spring’s constructor dependency injection.

6. Conclusion

I know, I know. This might not be the answer you all wanted, but we just cannot simply replace Lombok with records.

There’s a lot of hatred against Lombok, probably caused by its abusive and inappropriate usage.

Though, we have to admit that, if it is used properly it can be a great tool. We can enforce this through good coding practices, pair programming, and attentive code reviews.

As a wise man once said, when he initially found out about Lombok:

“With great power, comes great responsability“

— Spiderman, web developer

Photo by Ruben Sukatendel on Unsplash

Thank You!

Thanks for reading the article and please let me know what you think! Any feedback is welcome.

If you want to read more about clean code, design, unit testing, functional programming, and many others, make sure to check out my other articles.

If you like my content, consider following or subscribing to the email list.

Finally, if you consider becoming a Medium member and supporting my blog, here’s my referral.

Happy Coding!

Java
Software Development
Programming
Clean Code
Software Engineering
Recommended from ReadMedium