What is Lombok and why use it?

It can be time-consuming to create and review boilerplate code (which refers to sections of code that have to be included in many places with little to no alteration – Wikipedia).

Readability is one of the most important paradigms in modern software development. Lombok can help create cleaner code by reducing the viewable code footprint. This is possible because the annotations are interpreted at compile time, and it then generates the corresponding functions into the compiled classes. This can help newer developers by making classes appear less intimidating, boosting their confidence and give them more time to understand the overall architecture. It also provides benefits to more experienced developers by allowing them to focus on more complex logic and problems. By consequence the code review experience will also be improved and time will be gained.

Below is an example of annotations commonly used, followed by the generated class after compilation of the code for comparison:

@Getter             //Lombok annotation
@Setter             //Lombok annotation
@ToString           //Lombok annotation
@NoArgsConstructor  //Lombok annotation
@AllArgsConstructor //Lombok annotation
@Entity
@Table(name = "nerd")
public class Nerd {
    @Id
    @GeneratedValue(strategy= GenerationType.IDENTITY)
    private int id;
    private String name;
    private int age;
    private Double experience;
    @ElementCollection
    private List<String> skills;
}

Generated Class with the above annotations:

@Entity
@Table(
name = "nerd"
)
public class Nerd {
@Id
@GeneratedValue(
strategy = GenerationType.IDENTITY
)
private int id;
private String name;
private int age;
private Double experience;
@ElementCollection
private List<String> skills;

    public int getId() {
        return this.id;
    }

    public String getName() {
        return this.name;
    }

    public int getAge() {
        return this.age;
    }

    public Double getExperience() {
        return this.experience;
    }

    public List<String> getSkills() {
        return this.skills;
    }

    public void setId(final int id) {
        this.id = id;
    }

    public void setName(final String name) {
        this.name = name;
    }

    public void setAge(final int age) {
        this.age = age;
    }

    public void setExperience(final Double experience) {
        this.experience = experience;
    }

    public void setSkills(final List<String> skills) {
        this.skills = skills;
    }

    public String toString() {
        return "Nerd(id=" + this.getId() + ", name=" + this.getName() + ", age=" + this.getAge() + ", experience=" + this.getExperience() + ", skills=" + this.getSkills() + ")";
    }

    public Nerd() {
    }

    public Nerd(final int id, final String name, final int age, final Double experience, final List<String> skills) {
        this.id = id;
        this.name = name;
        this.age = age;
        this.experience = experience;
        this.skills = skills;
    }

}

To find more annotations and examples take a look at the existing documentation found on the Lombok website.

While Lombok offers a great opportunity to clean up code as well as improve code reviews and the coding workflow, it is best to keep in mind that it still needs to be used carefully. One thing I have encountered that could be difficult to catch would be the use of the @EqualsAndHashCode method. This will always generate equals comparators, but you might need to use compareTo for some specific data types (i.e: BigDecimal). Always read the small print from the documentation as it might mention undesirable side effects and sometimes lead you in the right direction to prevent them. Another thing to keep in mind is that the overuse of Lombok could hide some underlying issues in the architecture by abstracting constructor dependencies or even adding unnecessary methods. As a rule of thumb, always be mindful of the abstraction any library creates. Any architecture will benefit from a well-thought-out plan and an overall understanding of the system intricacy. If an annotation is not needed for the specific class, simply don’t use it. There are some risks outlined in this great article by Thorben Janssen that explains the risks of using specific annotations in Entity classes.

A recurrent argument I found against using Lombok was “what happens if the library switches to a non-free version?”. IntelliJ offers a way to remove any Lombok annotations using the “DeLombok” option under the refactor tab. If you do not have IntelliJ you can use the Lombok Maven Plugin to do it through Maven. If it ever comes to that, you can always transition pretty smoothly to a Lombok free code base using one of these options, et voilà.

Add Lombok to a Java Project.

There are multiple ways this can be handled:

1. When generating your Spring Boot project using the Spring Initialzr, Lombok can be added as a Dependency using the “ADD DEPENDENCIES” button. Then selecting the Lombok library:
2. There are many other ways Lombok can be added to existing projects. The Lombok setup documentation does a great job detailing them.

IntelliJ Setup.

Lombok is supported without a plugin for version 2020.3 and over. Prior to version 2020.3, the Lombok plugin must be installed (i.e: search Lombok in Marketplace tab, which is accessed via Settings/Preference -> Plugins). Intellij will need to be restarted after the plugin was installed.

Now that you know more about the Lombok library, it is time to start thinking about how it can fit in your development cycle and how it can help make your code more readable.

Enjoy!

The post Improve readability in your Java projects using the Lombok library appeared first on Big Nerd Ranch.