I admit that Lombok is a very good Java library. It allows you to play cool while writing less code. With a few simple annotations, you can kill a large piece of template code. However, all the source code is often used for reading, and only a little time is used for execution.
A year ago, most people and I thought that the emergence of Lombok would make the Java coding experience better, and strongly recommended the use of Lombok in my team. A year later, I began to worry about this, especially when I was preparing to upgrade the Java version of the open source blog system una boot, I realized that Lombok had fallen into a trick trap. After further analyzing its source code and understanding the working principle of relevant annotations, I found that I did not need to use a non-standard third-party library to convert Java into a sophisticated and cool language. The introduction of Lombok made my project happy for a while, but the price of it was that as the project progressed, technical debt began to accumulate.
Next, I will use several familiar scenes to repeat how I fell into Lombok's trick trap.
The beginning of love, the origin of hate
In the face of many "God walks" provided by Lombok, you don't mind adding a plug-in to the IDE. For IntelliJ IDEA players, just search "Lombok Plugin" to find this artifact and install it. Falling in love with Lombok starts with the installation of Lombok plug-in, and hatred sprouts from then on.
Before using Lombok, our source code looks 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+
"}";
}
}
Each JavaBean is filled with template code such as Getter, Setter, equals, hashCode and toString, It looks like a fat person (I have to admit that Java is a defective programming language). After we install Lombok plug-in, IDE can recognize its cool annotations. After using Lombok's @ Getter and @ Setter annotations, the code will look very slim as follows:
@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+
"}";
}
}
You think that's all Lombok can do? It can also make your code's "body" slimmer and more devilish. There is still room for improvement in the above code. We can replace the @ EqualsAndHashCode annotation with the equals and hashCode methods:
@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+
"}";
}
}
Does the code look much better now? But this is not the best time. Since other methods have been replaced, remove the ToString method as well As 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;
}
After Lombok's trick, does it look cool, slim and sexy compared with the original code? You think it's over? Far more than that. You will find that a large lump of annotation on the class name looks awkward. Lombok provides a combined annotation @ Data, which can replace the lump like Xiang on the head of the class name:
@Data
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
}
Now, does Lombok make your object perfect in your mind? The devil's "figure" is cool and refined. Lombok has other annotations, such as @ Slf4j, @ NoArgsConstructor, @ AllArgsConstructor, etc. it is not the focus of this article to introduce the usage of Lombok.
The above process of changing the number of lines of code may be the main reason why countless programmers fall in love with Lombok. It's like a fat person gradually becoming a slim person. Also let you see a phenomenon: do you think programmers are lazy? Other times they are lazier than you think. At the same time, it also planted a curse for the code.
If you are learning Spring Boot, we recommend a free tutorial that has been continuously updated for many years: http://blog.didispace.com/spring-boot-learning-2x/
Distorted aesthetics, hidden dangers of love
Distorted aesthetics leads to the sub-health of the examined objects. After using the Lombok plug-in, our code is also in a "sub-health" state. Or return to the first sentence: most of the source code is used to read, and only a little time is used to execute.
In essence, we all pursue to reduce the template code in the program to make the code more concise and concise, so as to improve the readability and maintainability of the code. However, Lombok did not achieve the vision we pursued. It just used a very clever way to take advantage of the gap between the compilation time of the Java language, Injecting (writing) the methods we need into the current class is like hack ing our code. It's just a cool trick. This trick is not intelligent and safe, but will destroy the existing features of Java code and the readability of the code. Next, combined with my own experience after using Lombok, let's talk about some major pain points brought by Lombok.
1.JDK version problem
When I wanted to upgrade the JDK of my existing project from Java 8 to Java 11, I found that Lombok didn't work properly. So I have to clear all Lombok annotations from the project source code, and use the functions of the IDE to generate getter/setter, equals, hashCode, toString and constructor. You can also use Delombok tool to complete this process. But it will eventually consume a lot of your time.
2. Coercive use
When Lombok is used in your source code, and it happens that your code is used by others, those who rely on your code must also install Lombok plug-in (whether they like it or not), and spend time to understand the use of Lombok annotations. If they don't do that, the code will not work normally. After using Lombok, I found that this is a very rogue behavior.
3. Poor readability
Lombok hides the details of JavaBean encapsulation. If you use the @ AllArgsConstructor annotation, it will provide a giant constructor, giving the outside world the opportunity to modify all properties in the class when initializing the object. First of all, this is extremely unsafe because we don't want to modify a family attribute in the class; In addition, if dozens of attributes exist in a class, a constructor containing dozens of parameters will be injected into the class by Lombok, which is irrational behavior; Secondly, the order of constructor parameters is completely controlled by Lombok. We can't control it. Only when you need debugging can you find a strange "Xiaoqiang" waiting for you; Finally, before running the code, you can only imagine what all the methods in JavaBeans look like, and you can't see them.
4. Increased code coupling
When you use Lombok to write the code of a module, other codes that depend on this module need to introduce Lombok dependencies, and Lombok plug-ins need to be installed in the IDE. Although Lombok's dependent package is not large, because Lombok is used in one place, all other dependent parties must be forced to join Lombok's Jar package, which is an invasive coupling. If there is a JDK version problem again, it will be a disaster.
5. The gains outweigh the losses
Using Lombok is fun for a while, but it pollutes your code, destroys the integrity, readability and security of Java code, and increases the technical debt of the team. This is an operation that does more harm than good. If you really want to make your code more refined while taking into account readability and coding efficiency, you might as well use the mainstream Scala or Kotlin, a JVM based language.
summary
Lombok itself is an excellent java code library. It uses a clever syntax sugar to simplify java coding and provide a way to simplify java code. However, when using this code library, you need to understand that Lombok is not a standard Java library. Using Lombok will increase the technical debt of the team, reduce the readability of the code, and increase the coupling degree and mode difficulty of the code. Although Lombok reduces the writing of template code to a certain extent, it also brings some unknown risks. If you are participating in a team project (or large-scale project), please communicate with your team and think twice about whether to use Lombok in consideration of subsequent upgrading and expansion.
So, what do you think of Lombok? Is it a code artifact? Or the culprit of sub-health? Leave a message and tell me your opinion!
This article is transferred from: program DD
Content reproduced from: Toutiao com/a6820517160964588044/