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?
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.
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 broke your code. The probability is low but I always feel uncomfortable using non-public APIs.
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.
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.
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.
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 :)
来源：https://stackoverflow.com/questions/4589184/what-are-the-risks-with-project-lombok