If you’re reading this, you’ve probably been familiar with Project Lombok for a while. Are you ready to embrace Lombok? Or are you ready to pitch such a cool project to your team? If you’re ready to do that, listen to some of my feelings after a year of using Lombok.

Lombok, I admit, is a great Java library that allows you to write less code and be cool. With a few simple comments, you can kill a lot of template code. However, all source code is read a lot of the time, and very little time is spent executing (you can fine print that).

A year ago, I and most people agreed that Lombok would make the Java coding experience better and strongly recommended Lombok to my team. A year later, I began to worry about this, especially when I was about to upgrade the Java version of una-Boot, an open source blogging system, and realized Lombok had fallen into a trick trap of its own. After I analyzed the source code further and understood how the annotations worked, I realized that I didn’t need to use a non-standard third-party library to turn Java into a slick, cool language. Introducing Lombok made my project feel good for a while, but at the cost of the technical debt that accumulated as the project progressed.

Here, I’ll reenact how I fell into Lombok’s trick with a few familiar scenes.

The beginning of love, the beginning of hate

With all the “magic moves” Lombok offers, you don’t mind adding a plug-in to your IDE. For IntelliJ IDEA players, simply search the “Lombok Plugin” to find the artifact and install it. The love of Lombok started when you installed the Lombok plugin, and the hate grew from there.

Before Lombok, our source code looked like this:

public class MyObject{
    private Long id;
    private String name;
    private int age;
    private int gender;

    public Long getId() {return id;
    }
    public void setId(Long id){
        this.id = id;
    }
    public String getName() {return name;
    }
    public void setName(String name){
        this.name = name;
    }
    public int getAge() {return age;
    }
    public void setAge(int age){
        this.age = age;
    }
    public int getGender() {return gender;
    }
    public void setGender(int gender){
        this.gender = gender;
    }

    @Override
    public boolean equals(Object o){
        if(this == o){
            return true;
        }
        if(o == null || getClass() ! = o.getClass()){return false;
        }
        MyObject obj =  (MyObject) o;
        return age = obj.age &&
            gender = obj.gender &&
            Objects.equals(id,obj.id) && 
            Objects.queals(name,obj.name);
    }

    @Override
    public int hashCode() {return Objects.hash(id,name,age,gender);
    }

    @Override
    public String toString() {return "MyObject{"+
            "id="+id+
            "name="+name+
            "age="+age+
            "gender="+gander+
            "}"; }}Copy the code

Every JavaBean is filled with template code for getters, setters, equals, hashCode, and toString, which makes it look like a fat person (admittedly Java is a flawed programming language). Once the Lombok plug-in is installed, the IDE can recognize its cool annotations. Using Lombok’s @getter and @setter annotations, the code looks slim like this:

@Getter
@Setter
public class MyObject{
    private Long id;
    private String name;
    private int age;
    private int gender;

    @Override
    public boolean equals(Object o){
        if(this == o){
            return true;
        }
        if(o == null || getClass() ! = o.getClass()){return false;
        }
        MyObject obj =  (MyObject) o;
        return age = obj.age &&
            gender = obj.gender &&
            Objects.equals(id,obj.id) && 
            Objects.queals(name,obj.name);
    }

    @Override
    public int hashCode() {return Objects.hash(id,name,age,gender);
    }

    @Override
    public String toString() {return "MyObject{"+
            "id="+id+
            "name="+name+
            "age="+age+
            "gender="+gander+
            "}"; }}Copy the code

You think that’s all Lombok can do? It also makes the “body” of your code slimmer and more diabolical. There is still room for improvement in the above code. We can replace the equals and hashCode methods with the @equalSandHashCode annotation:

@Getter
@Setter
@EqualsAndHashCode
public class MyObject{
    private Long id;
    private String name;
    private int age;
    private int gender;

    @Override
    public String toString() {return "MyObject{"+
            "id="+id+
            "name="+name+
            "age="+age+
            "gender="+gander+
            "}"; }}Copy the code

Does the code look better now? But that’s not the best part. Now that the other methods have been replaced, let’s get rid of the toString method as well. If you wish, you can use the @toString annotation to remove the method for:

@Getter
@Setter
@EqualsAndHashCode
@ToString
public class MyObject{
    private Long id;
    private String name;
    private int age;
    private int gender;
}
Copy the code

After Lombok’s sleight of hand, does it look cooler, slimmer, and sexier than the original code? You think this is the end of it? It’s much more than that. Lombok provides a composite annotation @data to replace the shit in class names:

@Data
public class MyObject{
    private Long id;
    private String name;
    private int age;
    private int gender;
}
Copy the code

Now, does Lombok make your date the perfect person for you? The devil’s “figure” is cool and refined. Lombok has other annotations such as @slf4j, @Noargsconstructor, @Allargsconstructor, etc. Introduction to Lombok usage is not the focus of this article.

This process of changing lines of code is probably the main reason so many programmers fall in love with Lombok, like a fat person becoming a thin person. It also shows you a phenomenon: do you think programmers are lazy? Other times they’re lazier than you think. While it’s fun, it’s also a curse for the code.

Distorted aesthetics, hidden dangers of love

Distorted aesthetic, resulting in the subject being examined in a state of sub-health. With the Lombok plug-in, our code is also in sub-health. To go back to the beginning: all source code is read a lot of the time, and very little of it is executed.

In essence, we all seek to reduce boilerplate code in our programs to make their code more concise and thus more readable and maintainable. Lombok doesn’t live up to the vision we’re looking for, however. It just takes advantage of the Java language’s compile-time hijacks to inject (write) the methods we need into our current class in a neat way, much like hacking our code, which is just a cool trick to look at. This trick is not smart or secure, but destroys the existing features of Java code and the readability of the code. Here are some of Lombok’s biggest pain points, based on my own experience with Lombok.

1. JDK version problem

When I tried to upgrade the JDK for an existing project from Java 8 to Java 11, I found Lombok didn’t work. I had to remove all Lombok annotations from the project source code and use the IDE’s built-in functionality to generate getters/setters, equals, hashCode, toString, constructors, etc. You can also use the Delombok tool to do this. But it’s going to take a lot of time.

2. Coercive use

When Lombok is used in your source code and your code is used by someone else, the people who rely on your code must also install Lombok plug-ins (whether they like them or not) and take the time to understand the use of Lombok annotations, otherwise the code will not work. After using Lombok, I found this to be a very rogue behavior.

3. Poor readability

Lombok hides the details of JavaBean encapsulation, and if you use the @Allargsconstructor annotation, it provides a giant constructor that gives outsiders the opportunity to modify all the properties in a class when initializing an object. First of all, it’s extremely insecure, because there’s a set of attributes in the class that we don’t want to change; Also, if there are dozens of attributes in a class, Lombok will inject a constructor with dozens of parameters into the class, which is irrational; Second, the order of the constructor arguments is completely controlled by Lombok, and we can’t control it until you need to debug to find a strange “cockroach” waiting for you. Finally, all the methods in Javabeans you can only imagine what they look like before you run the code, you can’t see them.

4. Code coupling degree increased

When you use Lombok to write code for a module, the rest of your code that relies on that module needs to incorporate Lombok dependencies and install Lombok plug-ins in your IDE. Lombok’s dependencies are small, but just because Lombok is used in one place, all the other dependencies have to be forced into Lombok jars, an intrusive coupling that can be a disaster if JDK versioning comes up.

5. You lose more than you gain

Lombok may feel good for a while, but it pollutes your code, undermines the integrity, readability, and security of Your Java code, and adds to your team’s technical debt, a practice that does more harm than good. If you really want your code to be more concise, readable and efficient, you can use a major JVA-BASED language like Scala or Kotlin.

conclusion

Lombok is an excellent Java code library on its own, using a sneaky syntactic sugar that simplifies Java coding and provides a way to simplify Java code, but you need to be aware that Lombok is not a standard Java library when you use it. Using Lombok increases the technical debt of the team, reduces the readability of the code, and increases the coupling and modality of the code. While Lombok reduces boilerplate writing to some extent, it also introduces some unknown risks. If you are working on a team project (or a large one), talk to your team and think twice about using Lombok for future upgrades and expansions.