Recently, I found that many people have mixed opinions on Lombok, which aroused my interest, because lombok is also widely used in our project. I have been confused by the different opinions of everyone for a few days. Today, BASED on my actual project experience, I would like to share with you my personal suggestions. A casual search turned up these articles:

These people suggested lombok as a magic tool that could greatly improve coding efficiency and make code more elegant. While searching, some articles are not recommended:

These people feel that it has a few holes, easy to put a hidden danger to the project, who should we listen to? Why is Lombok recommended? Before Lombok, we used to define Javabeans like this: public class User {

private Long id; private String name; private Integer age; private String address; public User() { } public User(Long id, String name, Integer age, String address) { this.id = id; this.name = name; this.age = age; this.address = address; } public Long getId() { return id; } public String getName() { return name; } public Integer getAge() { return age; } public String getAddress() { return address; } public void setId(Long id) { this.id = id; } public void setName(String name) { this.name = name; } public void setAge(Integer age) { this.age = age; } public void setAddress(String address) { this.address = address; } @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() ! = o.getClass()) return false; User user = (User) o; return Objects.equals(id, user.id) && Objects.equals(name, user.name) && Objects.equals(age, user.age) && Objects.equals(address, user.address); } @Override public int hashCode() { return Objects.hash(id, name, age, address); } @Override public String toString() { return "User{" + "id=" + id + ", name='" + name + '\'' + ", age=" + age + ", address='" + address + '\'' + '}'; }Copy the code

}

The User class contains member variables, getter/setter methods, constructors, equals, and hashCode methods. At first glance, there’s a lot of code. Also, if the code in the User class is changed, for example, the age field is changed to a string type, or the name of the name field is changed, do you need to synchronize the related member variables, getters/setters, constructors, equals, hashCode, all of them? Maybe some friends will say: the current idea is very smart, you can fix the modification at one time. Yeah, but there’s a more elegant way to do it. Lombok 1.18.4 Provided copy the code. Step 2 install the plugin in IDEA

Note: You cannot compile code using Lombok annotations without following the idea plugin. Step 3: Use lombok annotations in your code. The User class code above can look like this: @ToString @EqualsAndHashCode @NoArgsConstructor @AllArgsConstructor @Getter @Setter public class User {

private Long id;
private String name;
private Integer age;
private String address;
Copy the code

} Copy the code so good, the code can be optimized to be so simple. The body of the User class only defines the member variables, leaving all the other methods to the annotations. What if you change a member variable name or type? @ToString @EqualsAndHashCode @NoArgsConstructor @AllArgsConstructor @Getter @Setter public class User {

private Long id;
private String userName;
private String age;
private String address;
Copy the code

} You only need to modify the member variables and do not have to worry about the rest of the code, it is very cool. To make things even more exciting, you can optimize it further: @noargsconstructor @allargsconstructor @data public class User {

private Long id;
private String userName;
private String age;
private String address;
Copy the code

} the copy code @data is equivalent to a set of @getter, @setter, @toString, @equalSandhashCode, and @requiredargsConstructor. Lombok notes are as follows:

One of the biggest benefits of Lombok is that it’s a lot less code, a lot more efficient, and a lot more elegant. It’s a real gem. Java program parsing is divided into runtime parsing and compile-time parsing. Typically, we get classes, methods, annotations, and member variables through reflection, which is runtime parsing. But this way is not efficient, in order to run the program can be resolved. This is where compile-time parsing comes in handy. Compile-time parsing is divided into: The Annotation Processing Tool and the JSR 269 Pluggable Annotation Processing API are the first types of processors, which were first developed in JDK 1.5 Introduced along with annotations, it is a command-line tool that provides build-time source-based reading of a program’s structure and the ability to influence the compilation process by running an Annotation processor to generate new intermediate files. After JDK 1.8, however, the first processor was phased out in favor of the second processor. Let’s take a look at its processing flow:

The underlying implementation of Lombok is as follows:

Javac analyzes the source code and generates an abstract syntax tree (AST). During compilation, Lombok calls the Lombok program implementing “JSR 269 API”. Lombok then processes the AST obtained in the first step and finds the AST corresponding to the class where the @data annotation is located. Then modify the syntax tree (AST) to add corresponding tree nodes defined by getter and setter methods javac generates bytecode files using the modified abstract syntax tree (AST), that is, adding new nodes (code blocks) to the class

Why not recommend Lombok? Even though Lombok is a gem, many people don’t recommend using it. Why?

1. Forcing teammates to install the IDEA plugin is really gross, because writing code using Lombok annotations requires everyone involved in development to install the Lombok plugin for IDEA, otherwise the code will compile badly. With Lombok annotations, you don’t actually see the resulting code, you see it as it was before it was modified. If you want to see a reference to a getter or setter method, it’s very difficult. When someone was upgrading the JDK from Java 8 to Java 11, I found Lombok wasn’t working properly. 4. There are some pits

When using @data, @equalSandHashCode (callSuper=false) is used by default, and the generated equals() method only compares the attributes of the subclass, regardless of whether the attributes are inherited from the parent class.

Use @Builder with @allargsconstructor, otherwise an error may be reported.

5. Not easy to debug Most of us like to debug to locate problems, but lombok generated code is not easy to debug. If the fegin Client provided by the upstream system uses Lombok, the downstream system must also use Lombok. Otherwise, an error will be reported. The upstream and downstream systems have a strong dependency. How do we choose? Lombok has pros and cons. How do we choose? Personal advice to make the most reasonable choice according to the actual situation of the project.

If you are working on a new project and the upstream and downstream systems are new, lombok is recommended as it can significantly improve development efficiency. If you are working on an old project and have not used Lombok before, it is recommended that you do not use lombok in the future because of the high cost of code changes. If you have used Lombok in the past, it is recommended that you use lombok in the future because of the high cost of code modification. In fact, as long as the introduction of JAR package may have: mandatory teammates install IDEA plug-in, upgrade JDK impact on the function, some pits and upstream and downstream systems are strongly dependent on these problems, as long as the development of good specifications, summed up the use of experience these problems. I don’t think lombok is a big problem because it’s used on Javabeans, and the logic of that class is relatively simple. A lot of code can be read at a glance, and you can guess 7 or 8 out of 10 without debugging.

Finally, if this article is helpful to you, or inspired by it, please scan the QR code to pay attention to it. Your support is the biggest motivation for me to insist on writing. Ask for a key three even: like, forward, look.

Author: Su SAN said technology link: juejin.cn/post/690978… Source: Nuggets forward —- Su SAN said technology