Lombok is often said to be banned by companies elsewhere, and I have never understood why. Today I read an article that listed the “weaknesses” and I just want to refute them.

JDK version problems

When I tried to upgrade the JDK for an existing project from Java 8 to Java 11, I found Lombok didn’t work. I had to remove all Lombok annotations from the project source code and use the IDE’s built-in functionality to generate getters/setters, equals, hashCode, toString, constructors, etc. You can also use the Delombok tool to do this. But it’s going to take a lot of time.

My rebuttal: Many companies don’t change JDK versions for a long time once they decide on them (for example, many bank projects use JDK1.6, would they like to upgrade to JDK11?). Now it’s version 14, how many companies will upgrade! If many companies are using JDK1.8 now, I will continue to use JDK1.8 until you get to JDK14, and when you get to JDK20 I am sure Lombok will support a higher version and the compatibility issue will be gone.

Stress using

When Lombok is used in your source code and your code is used by someone else, the people who rely on your code must also install Lombok plug-ins (whether they like them or not) and take the time to understand the use of Lombok annotations, otherwise the code will not work. After using Lombok, I found this to be a very rogue behavior.

My rebuttal: It’s not up to you whether you like Lombok or not, it’s not up to you, it’s your job, you do what the company tells you to do, it’s the rules. Lombok is a very simple concept that can be used in ten minutes, but if you complain about the time it takes to learn Lombok, you will have to quit your job as a programmer.

Readability is poor

Lombok hides the details of JavaBean encapsulation, and if you use the @Allargsconstructor annotation, it provides a giant constructor that gives outsiders the opportunity to modify all the properties in a class when initializing an object.

First of all, it’s extremely insecure, because there’s a set of attributes in the class that we don’t want to change;

Also, if there are dozens of attributes in a class, Lombok will inject a constructor with dozens of parameters into the class, which is irrational;

Second, the order of the constructor arguments is completely dictated by Lombok, and you can’t control it until you need to debug to find a weird “roach” waiting for you.

Finally, all the methods in Javabeans you can only imagine what they look like before you run the code, you can’t see them.

My retort: Not happy with @Allargsconstructor you can use @Builder, which allows you to create any number of objects in any order. Lombok is bad if you don’t know any other uses of it. Do you want to look at methods in Javabeans? What’s cool about it, what’s cool about getters and setters, you don’t know what getters and setters look like? Really don’t understand what to see?

Code coupling degree increased

When you use Lombok to write code for a module, the rest of your code that relies on that module needs to incorporate Lombok dependencies and install Lombok plug-ins in your IDE.

Lombok’s dependencies are small, but just because Lombok is used in one place, all the other dependencies have to be forced into Lombok jars, an intrusive coupling that can be a disaster if JDK versioning comes up.



My retort: When we used other frameworks that introduced countless packages, it was a bit of a hassle to introduce a very small package. Lombok is so good that almost any project will use it.

the loss outweighs the gain

Lombok may feel good for a while, but it pollutes your code, undermines the integrity, readability, and security of Your Java code, and adds to your team’s technical debt, a practice that does more harm than good. If you really want your code to be more concise, readable and efficient, you can use a major JVA-BASED language like Scala or Kotlin.

My retort: Destroy integrity? Add the bloated Getter&Setter and you hate the bloated, don’t add you say break the integrity of the code, what do you want to do. Increasing the team’s technical debt? Ten minutes of Lombok learning is nothing to add. To use the Kotlin? Companies aren’t that aggressive, and many of Kotlin’s accessories aren’t ready for corporate use.

What other points of view can we discuss with each other?

Author: Java source of practical technology: toutiao.com/i6884399145390440964