Boilerplate Code Auto-Generation

Space Saving in Java Code

Have you ever noticed how many boilerplate things are there in every Java code? For example, when you write a model, you need to declare a no-argument constructor, a constructor with arguments, getters, setters, override the toString() and hashCode() methods, and much more. Typically, this takes up 70+ lines of code, making it difficult to spot additional logic in the class if it's present.

Conclusion: getters, setters, and additional boilerplate constructions can clutter your code significantly. However, there is an extension that effectively addresses this issue - Project Lombok.

Lombok

To get started with Project Lombok, we need to import it into the pom.xml (if you're using Maven):

Great, now we can start improving our code.

Let's take a look at some of the key annotations:

Getter and Setter

@Getter and @Setter: Generate standard getters and setters for a field. It can be applied at the field or class level.

Constructors

@NoArgsConstructor: Generates a no-argument constructor;
@RequiredArgsConstructor: Generates a constructor with one parameter for each field that requires special processing (such as fields annotated with @NonNull or final fields);
@AllArgsConstructor: Generates a constructor with one parameter for each field of the class.

Let's take a look at some code examples of how to apply these annotations.

These annotations should be placed above a class:

OldEmployee


              12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273
            
package com.example;

import java.util.Date;

public class Employee {

    private int id;

    private String name;

    private String position;

    private double salary;

    private Date hireDate;

    public Employee() {
    }

    public Employee(int id, String name, String position, double salary, Date hireDate) {
        this.id = id;
        this.name = name;
        this.position = position;
        this.salary = salary;
        this.hireDate = hireDate;
    }

    public int getId() {
        return id;
    }

    public Employee(String name, String position, double salary) {
        this.name = name;
        this.position = position;
        this.salary = salary;
    }

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

    public String getName() {
        return name;
    }

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

    public String getPosition() {
        return position;
    }

    public void setPosition(String position) {
        this.position = position;
    }

    public double getSalary() {
        return salary;
    }

    public void setSalary(double salary) {
        this.salary = salary;
    }

    public Date getHireDate() {
        return hireDate;
    }

    public void setHireDate(Date hireDate) {
        this.hireDate = hireDate;
    }
}

As you can see, this code looks quite lengthy, and it can be challenging to read anything in it, even though it's structured.

Let's improve it with the help of Lombok annotations:

improvedEmployee


              12345678910111213141516171819202122232425
            
package com.example;

import lombok.*;

import java.util.Date;

@Getter
@Setter
@AllArgsConstructor
@RequiredArgsConstructor
public class Employee {

    private int id;

    @NonNull
    private String name;

    @NonNull
    private String position;

    @NonNull
    private double salary;

    private Date hireDate;
}

So, from 73 lines, we've reduced it to 25. Now, we can clearly see what fields are in this class, that there are getters, setters, a constructor that takes all arguments, and a constructor that takes 3 arguments: name, position, and salary. In this way, we have significantly reduced the code while retaining the same functionality.

Additional Annotations:

Project Lombok also provides additional annotations, such as those for overriding toString(), equals(), and hashCode().

Let's take a look at some additional annotations that can be useful:

Here are some additional annotations in Markdown format:

Annotation	Description
`@ToString`	Generates a `toString()` method for the class.
`@EqualsAndHashCode`	Generates `equals(Object other)` and `hashCode()` methods.
`@NonNull`	Marks a field as not allowing null values and automatically generates corresponding checks.
`@Value`	Marks the class as immutable, adding `@Getter`, and making all fields `final` and `private`.
`@Data`	Combines `@Getter`, `@Setter`, and `@RequiredArgsConstructor`.

Now, let's further improve our code by replacing @Getter, @Setter, and @AllArgsConstructor with the @Data annotation, which is placed before the class keyword. Additionally, let's add the @ToString and @EqualsAndHashCode annotations.

The result will be the following code:

ImprovedImprovedEmployee


              123456789101112131415161718192021222324
            
package com.example;

import lombok.*;

import java.util.Date;

@EqualsAndHashCode
@ToString
@RequiredArgsConstructor
public @Data class Employee {

    private int id;

    @NonNull
    private String name;

    @NonNull
    private String position;

    @NonNull
    private double salary;

    private Date hireDate;
}

Note

We haven't covered all the annotations from the Project Lombok library. This chapter covers the main annotations and functions of this library. In the future, if we need to use a specific annotation that I haven't described in this chapter, I will explain separately what that particular annotation means.

In summary, Lombok is a powerful tool for optimizing Java code, but its usage requires some caution. All changes are made during compilation, and you'll need to install the Lombok plugin in your integrated development environment (IDE) to see these changes reflected. Additionally, it's worth noting that excessive use of Lombok can make it challenging to read and debug code if developers are not accustomed to this style.

In our course, we will use Lombok because we will be working extensively with entities, which take the form of model classes.

Everything was clear?

Thanks for your feedback!

Section 1. Chapter 5