The new technical director went so far as to ban all development within the company from using Lombok. However, no clear and convincing reasons were given.
So he came to chat with me and asked me whether this request was reasonable. Regarding this matter, I think the technical director's starting point is good, but his approach is a bit extreme.
The reason why I say that the starting point is good is because using Lombok does bring a lot of problems, and I personally don't actively use it at work.
The reason why I don’t actively use it is because some colleagues’ codes are still used, so I am also forced to install Lombok’s plug-ins.
Now that I have talked about this topic, I will briefly talk about some of my views.
What are the benefits of Lombok?
Lombok is a very practical Java tool that can be used to help developers eliminate Java's verbose code, especially for simple Java objects (POJO). It does this through annotations.
If you know more about Lombok, you can skip this paragraph first and look back directly. If you are not very familiar with it, you can simply understand it.
To use Lombok in a project, three steps are required:
1. Install the Lombok plugin in the IDE
Currently Lombok supports a variety of IDEs, including mainstream Eclipse, Intellji IDEA, Myeclipse, etc.
The installation method in IDEA is as follows:
2. Import related dependencies
Lombok supports the use of multiple build tools to import dependencies. Currently, it mainly supports maven, gardle, ant, etc.
For example, the import method using maven is as follows:
<dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
<scope>provided</scope>
</dependency>
3. Use annotations in the code
Lombok simplifies code mainly through annotations, among which @Data, @Getter/@Setter, @Builder, @NonNull, etc. are commonly used.
If you use the @Data annotation, you can simply define a Java Bean:
import lombok.Data;
@Data
public class Menu {
private String shopId;
private String skuMenuId;
private String skuName;
}
Using the @Data annotation on the class is equivalent to using @ToString, @EqualsAndHashCode, @Getter, @Setter and @RequiredArgsConstrutor annotations at the same time, which is very useful for POJO classes.
That is, it automatically helps to define methods such as toString, Getter, and Setter in the Menu class in the example.
Through the above example, you can find that we use the @Data annotation to greatly reduce the amount of code and make the code very concise. This is also the main reason why many developers are keen to use Lombok.
In addition, different people have different opinions on the use of Lombok, because many people have used Lombok and are familiar with its advantages, so let's focus on what problems the use of Lombok will bring.
What's so bad about Lombok?
Strong X teammates
Because the use of Lombok requires developers to install the corresponding plug-ins in the IDE.
If the plug-in is not installed, if you use the IDE to open a Lombok-based project, you will be prompted that the method cannot be found and other errors. Cause project compilation to fail.
In other words, if one person in the project team uses Lombok, then others must also install the IDE plug-in. Otherwise, there is no way to collaborate on development.
More importantly, if Lombok is used in a jar package we define, all applications that depend on this jar package must be required to install plug-ins, which is very intrusive.
Code readability and low debuggability
Using Lombok in the code can indeed help reduce a lot of code, because Lombok will help automatically generate a lot of code.
But these codes are only generated during the compilation phase, so in the development process, many codes are actually missing.
Extensive use of Lombok in the code will lead to a much lower readability of the code, and it will also bring certain problems to code debugging.
For example, if we want to know which classes refer to the getter method of a certain attribute in a certain class, it is not so simple.
There are pitfalls
Because Lombok makes code development very easy, this makes some developers over-rely on it.
In the process of using Lombok, if you don't understand the underlying principles of various annotations, it is easy to produce unexpected results.
To give a simple example, we know that when we use @Data to define a class, it will automatically generate the equals() method for us.
But if you only use @Data instead of @EqualsAndHashCode(callSuper=true), it will default to @EqualsAndHashCode(callSuper=false). At this time, the generated equals() method will only compare the attributes of subclasses and will not consider them. Attributes inherited from the parent class, regardless of whether the parent class attribute access rights are open or not.
This may lead to unexpected results.
Affecting the upgrade
Because Lombok is very intrusive to the code, it may cause a relatively big problem, that is, it will affect our upgrade of the JDK.
According to the current JDK upgrade frequency, a new version will be released every six months, but as a third-party tool, Lombok is maintained by an open source team, so its iteration speed cannot be guaranteed.
Therefore, if we need to upgrade to a new version of JDK, if the features are not supported in Lombok, it will be affected.
Another possible problem is that the upgrade of Lombok itself will also be limited.
Because an application may depend on multiple jar packages, and each jar package may depend on different versions of Lombok, this leads to the need for version arbitration in the application, and we know that jar package version arbitration is not so easy. And the probability of problems is also high.
Destruction of encapsulation
The above problems, I think there are ways to avoid them. But there is another important reason why some people reject the use of Lombok, that is, it will destroy encapsulation.
As we all know, the three major characteristics of Java include encapsulation, inheritance and polymorphism.
If we use Lombok directly in the code, it will automatically generate getter, setter and other methods for us, which means that all parameters in a class automatically provide setting and reading methods.
As a simple example, we define a shopping cart class:
@Data
public class ShoppingCart {
//商品数目
private int itemsCount;
//总价格
private double totalPrice;
//商品明细
private List items = new ArrayList<>();
}
We know that the number of items in the shopping cart, the item details, and the total price are actually related before, and if they need to be modified, they must be modified together.
However, we used Lombok's @Data annotation for the two attributes itemsCount and totalPrice. Although we define them as private types, public getter and setter methods are provided.
The outside can freely modify the values of these two properties through the setter method. We can call the setter method at will to reset the values of the itemsCount and totalPrice attributes, which will also cause them to be inconsistent with the values of the items attribute.
The definition of object-oriented encapsulation is: through access control, internal data is hidden, and the outside can only access and modify internal data through the limited interface provided by the class. Therefore, exposing setter methods that should not be exposed clearly violates the object-oriented encapsulation feature.
A good practice should not provide getter/setter, but only provide a public addItem method, and at the same time modify the three attributes of itemsCount, totalPrice and items.
Summary
This article summarizes the advantages and disadvantages of Lombok, a commonly used Java development tool.
The advantage is that using annotations can help to automatically generate code, which greatly reduces the amount of code and makes the code very concise.
But it does not mean that there are no problems in the use of Lombok. In the process of using Lombok, there may also be problems such as being unfriendly to teammates, unfriendly to code, unfriendly to debugging, and unfriendly to upgrades.
On top of that, using Lombok also leads to the problem of breaking encapsulation.
Although there are many conveniences in using Lombok, it also brings some problems.
But whether it is recommended to use it in daily development or not, I actually maintain a neutral attitude. I don't recommend that you rely too much on it, and I don't require you to completely use it.
As long as you think about its advantages and the problems it brings to the code before evaluating whether to introduce Lombok in the code, then the purpose of this article will be achieved!