It is often said elsewhere that companies are forbidden to use Lombok, but I have never understood why not. Today I read an article that listed some “disadvantages” and here I just wanted to rebut it with a vengeance.

JDK version issues

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

My rebuttal: a lot of companies do not change the JDK for a long time once they have established it (for example, many banking projects are using JDK 1.6, would you like to upgrade to JDK11?) Now it is out to version 14, you see how many companies will upgrade! If you go to JDK14, I will continue to use JDK1.8. By the time you get to JDK20, I’m sure Lombok will support a higher version and compatibility issues will be gone.

Stress using

When you use Lombok in your source code, and your code happens to be used by other people, the people who depend on your code must also install Lombok plugins (whether they like it or not) and spend time understanding how Lombok’s annotations are used, otherwise the code won’t work. Having used Lombok, I’ve found this to be very rogue behavior.

My rebuttal: Whether you install Lombok or not is not a matter of liking or not. It’s not up to you. It’s a job. Lombok is a very simple knowledge, you can use it in ten minutes, but you complain that it takes time to learn, as a programmer is not learning all the time, you have to give up the programmer job!

Readability is poor

Lombok hides the details of javabeans’ encapsulation. If you use the @AllargsConstructor annotation, it provides a giant constructor that gives the outside world the opportunity to modify all the properties of the class when initializing the object.

First, it’s extremely unsafe because there are certain properties in the class that we don’t want to be modified.

In addition, if there are dozens of attributes in a class, a constructor with dozens of parameters will be injected by Lombok into the class, which is irrational;

Second, the order of the constructor parameters is completely Lombok’s, and we can’t control it. Only when you need to debug will you find a strange “cockroaches” 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 satisfied with @AllargsConstructor you can use @Builder, which allows you to create any number of objects in any order, and you can say Lombok is bad if you don’t know anything about its other uses. You want to look at a method in a JavaBean? What’s nice about it, what’s nice about getters and setters, don’t you know what getters and setters look like? I don’t know what to look at.

Code coupling increases

When you use Lombok to write code for a module, all other code that depends on that module will need to introduce Lombok dependencies, as well as install Lombok plug-ins in the IDE.

Although Lombok’s dependencies are not large, just because one of them uses Lombok, all the others are forced into the Lombok Jar, which is an invasive coupling that can be a disaster if you run into JDK version problems.

My remonition: When we used other frameworks, they introduced countless packages, and now it’s a bit of a hassle to introduce a small package. Lombok is so good that almost all projects use it. Why do we need to force it in?

the loss outweighs the gain

Using Lombok is fun for a while, but it pollutes your code, destroys the integrity, readability, and security of Your Java code, and increases your team’s technical debt. It’s a way of doing more harm than good. If you really want to make your code more readable and efficient, use mainstream Languages like Scala or Kotlin, which are based on the JVM.

My rebuttal: Damaged integrity? Add the bloat getter&setters and you hate bloat, and you say it breaks the integrity of the code, what do you want to do. Increasing your team’s technical debt? There’s nothing to add to learning Lombok for ten minutes. To use the Kotlin? Generally, companies are not so aggressive, and many of Kotlin’s accessories are still immature for enterprise use.

What other points of view can we discuss