Advantages and disadvantages of using Project Lombok

Project Lombok is a great library that can help you avoid writing boilerplate code and saves you precious time. But is it right for your project? Well, it really depends on the nature of your project and how you intend to use the library.

In this post, we will discuss the advantages and disadvantages of using Project Lombok in order to help you make an informed decision.

Advantages of using Project Lombok

When choosing a new library or a tool, you always need to take into consideration some aspects in order to increase your chances of success, and Lombok is no exception.

In this section, we discuss the advantages of using Lombok and some scenarios where Lombok would make sense.

Lombok saves you time (and money)

Let us get into the interesting stuff first. If you have checked our articles here and here, you will see examples of how much time you can save by using Lombok. Mindless hours of boilerplate code can be reduced to a few class annotations.

This not only saves you time, but theoretically money as well (time is money you know 😉 ). Think about all the paid time your team spends writing getters and setters, renaming them when renaming a variable, etc.

If your project has a lot of DTOs and POJOs, then it might be a good idea to consider using Lombok.

Lombok can make your code cleaner

Using Lombok in the right way can make your code cleaner and easier to read. Take for example this simple POJO written with Lombok.

@Data
public class MyCandlestick {

    private double high;

    private double low;

    private double open;

    private double close;

    private double volume;

    private long date;

}

This class is an example of a simple object which is used to hold simple data. By using the @Data annotation, we automatically added getters and setters for all those fields.

With time, you will get to know those annotations by heart. This means that just by looking at the @Data annotation, you will know which features the class provides. This is a much cleaner approach than having to manually write each and every getter and setter like this……

public class MyCandlestick {
    
    private double high;

    private double low;

    private double open;

    private double close;

    private double volume;

    private long date;

    public double getHigh() {
        return high;
    }

    public void setHigh(double high) {
        this.high = high;
    }

    public double getLow() {
        return low;
    }

    public void setLow(double low) {
        this.low = low;
    }

    public double getOpen() {
        return open;
    }

    public void setOpen(double open) {
        this.open = open;
    }

    public double getClose() {
        return close;
    }

    public void setClose(double close) {
        this.close = close;
    }

    public double getVolume() {
        return volume;
    }

    public void setVolume(double volume) {
        this.volume = volume;
    }

    public long getDate() {
        return date;
    }

    public void setDate(long date) {
        this.date = date;
    }
}

You can check out a summary of the most commonly used Lombok annotations and what they provide you in terms of functionalities and code savings in our post here.

Lombok is opensource

Project Lombok is an open source library. This means that you are not required to pay for it to use in your enterprise application. There is also a large community behind it, which means that issues are readily raised with the development team and are dealt with in future updates.

Another advantage of open source projects is that they are used by numerous other developers. This means that you can find answers to your questions on support forms.

You can read more about the Lombok license terms in this github link here.

Lombok has stood the test of time

Project Lombok has been around since 2009. Since 2014, it has been getting anywhere from 3 to 5 updates per year. Not many Java libraries and frameworks have been able to survive for such a long time.

This makes Lombok a safe bet for your project as you can count on it being updated to support newer JDK versions. You can check the change log of Project Lombok here.

Disadvantages of using Project Lombok

As with any library, there are pitfalls that you need to be careful of when using it. With Lombok, you can avoid these pitfalls if you know what you are dealing with and by not leaning too much on it.

Delomboking code can be difficult

If you google “disadvantages of project Lombok”, you will find a wide variety of posts by developers complaining how difficult was it for their team to move away from Lombok.

Lombok provides a tool to convert the Lombok annotations to their equivalent vanilla Java code. This tool is called Delombok. Delomboking your code can be done either through the command line or via your IDE.

However, as with any code generation or handling tool, it does not always produce the perfect result. So it might not be a good idea to use Lombok in each and every single Java class you have as it might be difficult to move back to plain Java later on if you need to.

IDE plugins are needed

When using Lombok, all that you need technically is to configure the dependency to the required libraries. However, your IDE will still not understand what these annotations mean and will keep complaining about those missing getters and setters.

For this, an IDE plugin is usually needed. Thanks to the Lombok community, we now have a plugin for most major Java IDEs out there.

However, if you are using lesser known IDEs or your aunt’s custom made ultimate Java IDE, then you might be out of luck.

Debugging Lombok code can be difficult

Lombok is meant to be used to generate boilerplate code. According to Wikipedia, the definition of boilerplate code is code that might be included in many places, but with little to no alterations. This also means that you usually do not need to debug boilerplate code as it does not change much between classes and usually does very simple tasks, such as setting variable values.

But if you do need to debug Lombok code, then you will have difficulties doing so. For example, on IntelliJ, as of the time of writing this article, you can debug Lombok code only by delomboking the code first!. After you delombok the code, you can set your breakpoints to start debugging.

Lombok and javadocs issues

Perhaps the biggest disadvantage of using Project Lombok is that generated code does not show up in the javadocs. This means that you will not find those public getters and setters in the generated javadocs.

However, with every problem, there is a solution (or a workaround). If you want to include the generated Lombok code into your javadocs, you will need to run delombok first and then use the generated source as the input for the javadoc plugin.

You can automate the process as follows.

<plugin>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok-maven-plugin</artifactId>
    <version>X.XX.X.X</version>
    <configuration>
        <sourceDirectory>${project.basedir}/src/main/java</sourceDirectory>
        <outputDirectory>${delombok.output}</outputDirectory>
        <addOutputDirectory>false</addOutputDirectory>
    </configuration>
    <executions>
        <execution>
            <!-- Generate delomboked code -->
            <phase>generate-sources</phase>
            <goals>
                <goal>delombok</goal>
            </goals>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-javadoc-plugin</artifactId>
    <version>X.X</version>
    <configuration>
        <!-- Use the delomboked output as the base for the javadocs -->
        <sourcepath>${delombok.output}</sourcepath>
    </configuration>
</plugin>

While this workaround will allow you to mention that the generated code exists, you still cannot add any additional data to the javadocs related to the generated code.

However, this should not be a gigantic issue as long as you don’t do anything fancy with Lombok.

When to use Lombok

Given all these advantages and disadvantages, you might still be unsure about using Project Lombok. I will not be able to tell you if Lombok is right for you or not. However, I can only provide my biased opinion which I will summarize in the following points:

If your project has a lot of POJOs and DTOs, then I would give Lombok a try and workaround any issues that might popup.
I would stick with Lombok’s basic features, such as constructor and getters and setters generation and stay away from fancy stuff such as the @Cleanup annotation. This makes it easier for you to move away from Lombok if you need to in the future.
Test every functionality before using it on a large scale and make sure you know how it works. For example, if you plan to add the @ToString annotation to Enums, then I would test it first on a small scale to see how it behaves before adding it to every other enum in your project. This makes things more understandable and easier to debug.
Focus on readability. If you use a few Lombok annotations here and there to avoid large amounts of repetitive code then it helps readability as it summarizes the features of the class. However, if you start stacking 5 or more Lombok annotations to make things final, synchronized, private, static and what not, then it just defeats the purpose. Keep it simple.
Make sure that your team is on the same page as you and discuss which features from Lombok to use and which to stay away from.
If you decide to move away from Lombok, then do so gradually. Remove Lombok annotations in parts, making sure that all tests are passing with each cycle before moving on to the next batch of annotations. Doing so might seem slower than just delomboking the whole project in one big bang. However, it might save you even more time and frustration debugging the delomboked code and trying to figure out what went wrong.
Share this post with your team mates.

Finally, I would really recommend that you check out the book “Head First Design Patterns: A Brain-Friendly Guide” (link to Amazon). Don’t be off-put by the book’s release date. The book is a valuable resource for learning about design patterns which can be applied accross different programming languages.

Not only do you get to learn about design patterns, but you also get to understand why every developer needs to know about them and implement them.

You can then apply the same principles and best practices mentioned in the book when deciding to choose a framework such as Lombok, which directly affects the way you code and the design patterns that you implement.