51

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?

jldugger
  • 2,339
  • 6
  • 22
  • 24

8 Answers8

39

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.

Koray Tugay
  • 22,894
  • 45
  • 188
  • 319
Jcs
  • 13,279
  • 5
  • 53
  • 70
32

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.

Krzysztof Tomaszewski
  • 1,033
  • 11
  • 16
  • I agree with this answer more than the accepted one. Lombok isn't restricting IDE usage anymore. It's just bringing Java into the modern days. Without Lombok, I would be screaming for my company to change the codebase to something less verbose, like Kotlin. – Guilherme Taffarel Bergamin Jul 13 '21 at 17:53
24

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.

michaelsnowden
  • 6,031
  • 2
  • 38
  • 83
Zeki
  • 5,107
  • 1
  • 20
  • 27
  • 6
    Wrong about only Eclipse: I use Project Lombok in Netbeans Dev just fine. And I think they support other IDE's as well – TheLQ Jan 03 '11 at 23:47
  • Things may be improving, but the criticism still remains that you will need explicit IDE support to use an IDE with a Lombok project. The point your project no longer qualifies as strictly Java code. – Zeki Jan 04 '11 at 01:57
  • If it's any consolation, I use Eclipse but some of the other Devs use IDEA, which doesn't yet appear to support Lombok. – jldugger Jan 04 '11 at 02:53
  • 17
    This answer is outdated. Both IntelliJ (via plugin) and NetBeans supports Lombok. – kctang Nov 17 '13 at 15:06
  • A related question: "Is it safe to use Project Lombok?" http://stackoverflow.com/questions/3852091/is-it-safe-to-use-project-lombok – Snekse Aug 21 '14 at 19:17
  • 1
    Update 2021 the latest version of Intellij Idea supports lombok out of the box starting from 2020.3. I don't feel its a problem with IDE anymore. As long as everyone in the team agrees with using Lombok it could only help in speeding up development time or slow it down if everyone in the team does what they want and there is no consensus on what should be the "Team Standard" – GauravEdekar Feb 11 '21 at 08:36
  • 1
    The very fact that you need an IDE support shows for me that Lombok is an antipatern. – alex Jan 13 '22 at 11:59
23

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.

Will Hartung
  • 115,893
  • 19
  • 128
  • 203
  • 6
    You may use http://projectlombok.org/features/delombok.html in order to get vanilla classes. – maaartinus Jan 21 '11 at 07:08
  • 2
    I fully agree on the "black magic" terminology. If you're familiar with it then you'll know what's going on, but if you're new to it, then it looks like your code is lying to you, a potential source of WTF moments – DanDan Feb 27 '19 at 09:15
6

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.

dehasi
  • 2,644
  • 1
  • 19
  • 31
  • There are documented ways around this already - use delombok before running sonar/checkstyle. But anyway, do you really want to have code coverage on your POJOs?! – Ali H Jul 23 '18 at 08:20
  • It's not about POJO coverage. Sonar says smth like `make this field private and add getter`. – dehasi Jul 26 '18 at 02:01
5

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

Community
  • 1
  • 1
Anil Bharadia
  • 2,760
  • 6
  • 34
  • 46
5

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.

Ashish Khandelwal
  • 611
  • 8
  • 6
  • 1
    Very much so. This is especially applicable where people may be coming from different programming backgrounds, namely non-JVM languages, where lombok is far less known. – A248 Aug 04 '20 at 00:18
4

To add to other responses.

The main reason to not use it is a new record keyword added as experimental feature in Java 14. Java 16 brings records out of preview which will make project Lombok obsolete in most cases.

Since Java 14 one is able able to write:

record Book(String title, String author, String isbn);

which gives automatically access to the constructor, getters/setter, hashCode, equals and toString methods without any annotations.

blekione
  • 10,152
  • 3
  • 20
  • 26