If you are reading this article, you must have known Project Lombok for some time. Are you ready to embrace Lombok? Or are you ready to recommend such a cool project to your team? If you are ready to do that, you might as well listen to some of my feelings after using Lombok for a year.
I admit that Lombok is a very good Java library, which allows you to be cool while writing less code. A few simple annotations can kill a large piece of template code. However, most of the source code is used for reading and very little time for execution (you can read this sentence in detail).
A year ago, most people and I thought that the advent of Lombok would make the Java coding experience better, and strongly recommended 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 I further analyzed the source code and understood the working principle of the relevant solution, 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 gave my project a temporary relief, but the price of the temporary relief was that as the project progressed, technical debt began to accumulate.
Next, I will use a few familiar scenes to repeat how I fell into Lombok's trick trap.
The beginning of love, the origin of hate
Faced with the many "god positions" provided by Lombok, you don't mind adding a plug-in to the IDE. For IntelliJ IDEA players, just search for "Lombok Plugin" to find this artifact and install it. Falling in love with Lombok started by installing the Lombok plug-in, and hatred has sprouted from then on.
Before Lombok was used, 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+
"}";
}}
Each JavaBean will be filled with template code such as the above getter, setter, equals, hashCode and toString, which looks like a fat person (have to admit that Java is a flawed programming language). After we install the Lombok plug-in, the IDE can recognize its cool annotations. After using Lombok's @Getter and @Setter annotations, the code will look slim like the following:
@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+
"}";
}}Does the current code look much cooler? But this is not the best time. Since the other methods have been replaced, take out the toString method as well. As you wish, you can use the @ToString annotation to remove the corresponding method:
@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+
"}";
}}After Lombok's trick, compared to the initial code, does it look cool, slim, and sexy? Do you think this is the end? It's much more than that. You will find that a large annotation on the class name looks awkward. Lombok provides a combination annotation @Data, which can replace the Xiang-like thing 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 the perfect look in your mind? The devil's "body" is cool and refined. Lombok also has some other annotations, such as @Slf4j, @NoArgsConstructor, @AllArgsConstructor, etc. The introduction of Lombok usage is not the focus of this article.
The change in the number of lines of code above may be the main reason why countless programmers fall in love with Lombok. It is like an obese person gradually becoming a slim person. Also let you see a phenomenon: Do you think programmers are lazy? Sometimes they are lazier than you think. While cool, it also planted the bane of the code.
Distorted aesthetics, hidden dangers of love
The distorted aesthetic results in the sub-healthy state of the object being examined. After using the Lombok plugin, our code is also in a "sub-healthy" state. Returning to the sentence at the beginning: All source code is used for reading most of the time, and only a little time is used for execution.
Essentially, we all seek to reduce the boilerplate code in the program to make the code more concise and concise, thereby improving the readability and maintainability of the code. But Lombok has not achieved the vision we are pursuing. It just uses the gap in the Java language at compile time and uses a clever way to inject (write) the methods we need into the current class. In this process, this kind of process is a lot like hacking our code, just a cool-looking trick. This kind of trick is not smart and safe, but will destroy the existing features of Java code and the readability of the code. Below, combined with my own feelings after using Lombok, talk about the major pain points caused by Lombok.
1. JDK version issues
When I wanted to upgrade the JDK of an existing project from Java 8 to Java 11, I found that Lombok was not working properly. So I had to remove all Lombok annotations from the project source code, and use the IDE's built-in functions to generate getter/setter, equals, hashCode, toString, and constructor methods. You can also use the Delombok tool to complete this process. But this will eventually consume a lot of your time.
2. Coercive use
When you use Lombok in your source code, and it happens that your code is used by other people, then people who rely on your code must also install the Lombok plugin (whether they like it or not), and spend time to understand Lombok The usage of annotations, if you don’t do that, the code will not run properly. 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 that gives 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 do not want to modify a certain attribute in a class; in addition, if there are dozens of attributes in a certain class, there will be a constructor containing dozens of parameters. Lombok is injected into the class, which is irrational; secondly, the order of the constructor parameters is completely controlled by Lombok, and we cannot control it. Only when you need to debug do you find a strange "Xiaoqiang" waiting for you ; Finally, before running the code, you can only imagine what they look like in all JavaBean methods, you can't see them.
4. Increased code coupling
When you use Lombok to write the code of a certain module, other codes that depend on this module need to introduce Lombok dependencies, and at the same time, you need to install Lombok plug-ins in the IDE. Although Lombok's dependency package is not large, just because Lombok is used in one place, all other relying parties must be forced to join Lombok's Jar package. This is an intrusive coupling. If you encounter JDK version problems again, This will be a disaster.
5. The gain is not worth the loss
Using Lombok, it feels great for a while, but it pollutes your code, destroys the integrity, readability and safety of Java code, and also increases the technical debt of the team. This is a kind of harm that outweighs the benefits. Operation. If you really want to make your code more refined, while taking into account readability and coding efficiency, you might as well use mainstream Scala or Kotlin, a JVM-based language.
to sum up
Lombok itself is an excellent Java code base. It uses a clever syntactic sugar to simplify the coding of Java and provide a way to streamline Java code. However, when using this code base, 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 and debugging difficulty of the code. Although Lombok reduces the writing of boilerplate code to a certain extent, it also brings some unknown risks. If you are participating in a team project (or large-scale project), considering the subsequent upgrade and expansion, whether to use Lombok, please communicate with your team and think twice.