What are the risks with Project Lombok?

Question

I'm coming up with performance goals for the new year, and I thought I'd be fun to put a goal to reduce the size of the code base, especially boilerplate. One action I've come up with to address this is to use Project Lombok to make beans as short as they should be. But I have a habit of overlooking downsides to new software and approaches, so I'm relying on the Stack Overflow community: Can anyone tell me why Lombok is a bad idea?

Answer 1

One potential disadvantage to something like Lombok is that with the setters/getters "missing", source tools may not "recognize" aspects of the resulting object that give it "bean" qualities, since those qualities only manifest in the compiled class.

Another disadvantage is that it's Yet Another piece of "black magic" within the tool chain. Fortunately, it seems to be a rather benign piece (I have not used it), and the fact that it happens at compile time rather than runtime is actually a blessing (IMHO). But, you're not going to be able to reuse or share your code without the project since it's adding artifacts to your code base. So, while the compiled class file may be a "POJO", I'd argue that your source code is NOT a POJO.

Neither of these are crippling downsides, rather just aspects to be aware of looking forward.

Answer 2

In my opinion, The most obvious risk with Project Lombok is that when you decide to use lombok, you also decide that everyone else who deals with your code uses lombok. This is a true statement for all libraries, but Lombok is special in that it is a build-time dependency and your IDE needs plugins to figure out what is going on. That means anyone who has reason to touch your code ex. someone trying to debug weird behavior, etc.) needs to know how to set it up and how it works. That can be a little frustrating.

Answer 3

As pointed out by user @Jcs in another answer, i would like to add more.

In our project we, are using mapstruct which is used to generate mapper classes, before the code is compiled, using mvn generate-sources command, this is done at process phase using maven processor plugin.

project lombok adds the bytecode for the getter/setter in class file at compile phase.

since process phase is executed before the compile, it finds that there is no getter/setter available in class.

There are some workarounds available to execute compile phase more than one. See this git hub ticket for more details.

Note : I am using STS ide by Spring and it is supported by lombok :)

Answer 4

A major downside is IDE support. Since Lombok is not actually a language change, and since your IDE only understands java, you will need an IDE that supports Lombok to get things working right. As of now, that's only Eclipse that includes Eclipse and IntelliJ. If you use eclipse that might be ok, but remember that you are making a decision for future developers as well.

I'd suggest you consider moving some of your code into a less ceremonial language such as groovy. We've had success moving some of our business logic and models into groovy and it works really smoothly.

Answer 5

It's a third party library, and there are developers who don't know it well.

IDE should support annotations processing (there are plugins for IDEA and Eclipse).

As was mentioned above, your code will be without getters/setters. It leads to sonar/checkstyle violations.

Answer 6

A limitation of Lombok is the fact that it is closely tied to the java compiler. Since the annotation processor API only allows creation of new files during the compilation (and not the modification of the existing files) lombok uses that API as a entry point to modify the java compiler. Unfortunately these modifications of the compiler make heavy usage of non-public APIs. Using lombok may be a good idea but you must be aware that upgrading your compiler may break your code. The probability is low but I always feel uncomfortable using non-public APIs.