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 com

Answer 1

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 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

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 4

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 5

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.

Answer 6

In my opinion source code in "Java+Lombok" is not Java source code anymore. I see it as something similar Borland company made many years ago in their Borland C++ Builder IDE for VCL - they introduced "properties" in C++ code effectively introducing some kind of a new programming language that wasn't C++ anymore (not C++ in sense of standard of C++ language). Sources using "Java+Lombok" are not valid sources in sense of Java language specification. Moreover I think annotations were not designed to influence language semantic.