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

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.