I have a boy, in a small Internet companies do Java back-end development, they recently company for a new chief technology officer, the chief technology officer for technical details value, then company after it launched a lot of “policy”, for example defines many development, logging, and even called unified use an IDE.

But that’s not what my junior was teasing me about. What he was teasing me about was how he couldn’t understand the fact that the new CTO had banned Lombok from all development within the company. But it doesn’t give a very clear, convincing reason.

So he came to chat with me and asked me if it was a reasonable request. In this regard, I think the technical director’s intentions are good, but his approach is a bit extreme.

Good intentions, because using Lombok does pose a lot of problems, and I personally don’t use Lombok actively at work.

I was forced to install Lombok’s plug-in because some of my colleagues were using it anyway.

While we’re on the subject, let me give you a few thoughts.

What’s so good about Lombok?

Lombok is a very useful Java tool to help developers eliminate Java’s verbose code, especially for simple Java objects (POJOs). It does this through annotations.

If you are familiar with Lombok, you can skip this paragraph and go straight to the future, if you are not familiar with Lombok, you can learn a little bit about it.

To use Lombok in a project, there are three steps:

Install Lombok in your IDE

Lombok currently supports a variety of ides, including mainstream Eclips, Intellji IDEA, Myeclipse, and more.

The installation method in IDEA is as follows:

Two, import related dependencies

Lombok supports importing dependencies using multiple build tools, including Maven, Gardle, and Ant.

For example, import using Maven as follows:

< the dependency > < groupId > org. Projectlombok < / groupId > < artifactId > lombok < / artifactId > < version > 1.18.12 < / version > <scope>provided</scope> </dependency>Copy the code

Use annotations in your code

Lombok uses annotations to simplify code, such as @data, @getter / @setter, @Builder, and @nonnull.

Using the @data annotation, we can simply define a Java Bean:

import lombok.Data;
@Data
public class Menu {
    private String shopId;
    private String skuMenuId;
    private String skuName;
}
Copy the code

Using an @Data annotation on a class is the equivalent of using @ToString, @EqualSandhashCode, @getter, @setter, and @RequiredargsConstrutor at the same time, which is quite useful for POJO classes.

The Menu class defines toString, Getter, Setter, and other methods.

As you can see from the example above, using the @data annotation greatly reduces the amount of code and makes the code very concise. This is one of the main reasons many developers are keen to use Lombok.

In addition, there are different opinions about Lombok’s use, and since many people have used Lombok and are familiar with its advantages, let’s focus on some of the problems that come with using Lombok.

What’s bad about Lombok?

Strong X teammates

The use of Lombok requires the developer to install the corresponding plug-in in the IDE.

Using the IDE to open a Lombok-based project will cause errors such as no method found if the plug-in is not installed. The project failed to compile.

That is, if one person on the project team uses Lombok, the rest of the team must also install the IDE plug-in. Otherwise, there’s no way to collaborate.

More importantly, if we define a JAR that uses Lombok, it would be intrusive to require plug-ins to be installed for all applications that rely on the JAR.

Code readability, low debuggability

Using Lombok in your code really helps reduce a lot of code because Lombok automatically generates a lot of code.

But the code is generated at compile time, so a lot of the code is actually missing during development.

The heavy use of Lombok in your code makes your code much less readable and causes problems with code debugging.

For example, if we want to know which classes reference the getter methods for a property in a class, it’s not so easy.

A pit

Because Lombok makes code development so easy, some developers become overly dependent on it.

When working with Lombok, it’s easy to have unexpected results if you don’t understand the underlying principles of various annotations.

As a simple example, we know that when we define a class using @data, it automatically generates equals() for us.

But if you use @data instead of @equalSandHashCode (callSuper=true), The default is @equalSandHashCode (callSuper=false), and the generated equals() method will only compare the attributes of the subclass, not those inherited from the parent class, whether or not the parent class has open access to the attributes.

This can have unexpected results.

Affect the upgrade

Because Lombok is so intrusive into the code, one of the bigger problems is that it affects how we upgrade the JDK.

At today’s rate of JDK upgrades, a new release is released every six months, but Lombok’s iteration rate is not guaranteed as it is a third-party tool and maintained by an open source team.

So, if we need to upgrade to a new version of the JDK, features that are not supported in Lombok will be affected.

Another potential problem is that Lombok’s own upgrades will be limited.

Because an application may rely on multiple JARS, and each JAR may depend on a different version of Lombok, versioning is required in the application, and we know that jar versioning is not easy and the probability of problems is high.

Breaking encapsulation

I think there are ways to avoid these problems. But there is another important reason why some people reject Lombok, and that is because it breaks encapsulation.

As you know, the three main features of Java are encapsulation, inheritance, and polymorphism.

If we use Lombok directly in our code, it automatically generates getters, setters, and so on for us, which means that all parameters in a class automatically provide set and read methods.

For a simple example, let’s define a shopping cart class:

@data public class ShoppingCart {private int itemsCount; Private double totalPrice; Private List items = new ArrayList<>(); } // Example from Geek Time: Beauty of Design PatternsCopy the code

We know that the number of items in the cart, the details of the items, and the total price were previously related and changed together if necessary.

However, we use Lombok’s @data annotation for the itemsCount and totalPrice attributes. Although we define them as private, we provide public getters and setters.

The values of these two properties can be arbitrarily modified externally via setter methods. We can arbitrarily call setter methods to reset the itemsCount and totalPrice properties, which will also cause them to be inconsistent with the items property values.

The definition of object-oriented encapsulation is that internal data is hidden through access control, and external data can only be accessed and modified through the limited interface provided by the class. Therefore, exposing setter methods that should not be exposed clearly violates the nature of object-oriented encapsulation.

Instead of providing getters/setters, it is good practice to provide only a public addItem method that takes the modified itemsCount, totalPrice, and Items properties.

conclusion

This article summarizes the pros and cons of Lombok, a commonly used Java development tool.

The advantage is that using annotations helps generate code automatically, greatly reducing the amount of code and making the code very concise.

But that doesn’t mean Lombok isn’t problematic. It can also be unfriendly to teammates, unfriendly to code, unfriendly to debugging, unfriendly to upgrading, and so on.

On top of that, using Lombok leads to the problem of breaking encapsulation.

While there are many advantages to using Lombok, there are also some problems.

However, it is not recommended to use it in daily development. I am actually neutral. I do not recommend over-reliance on it, nor do I require you to use it completely.

As long as you think about Lombok’s benefits as well as the problems it brings to your code before using it or evaluating whether or not to introduce it into your code, the purpose of this article will be met.

References:

Time.geekbang.org/column/arti…

projectlombok.org/