Take the 2-minute tour ×

In case you don't know, Project Lombok helps with some of the annoyances of Java with stuff like generating getters and setters with annotations and even simple JavaBean like generation with @Data. It could really help me, especially in 50 different event objects where you have up to 7 different fields that need to be constructed and hidden with getters. I could remove almost a thousand lines of code with this.

However I'm worried that in the long run it will be a regretful decision. Flamewars will erupt in the ##Java Freenode channel when I mention it, providing code snippets will confuse possible helpers, people will complain about missing JavaDoc, and future commiters might just remove it all anyway. I would really enjoy the positive, but I'm worried about the negative.

So: Is it safe to use on any project, small or large? Are the positive effects worth the negatives?

share|improve this question

put on hold as primarily opinion-based by Cupcake, Jan Dvorak, random, Max Galkin, Divi Jul 6 at 4:25


add comment

10 Answers

up vote 42 down vote accepted

It sounds like you've already decided that Project Lombok gives you significant technical advantages for your proposed new project. (To be clear from the start, I have no particular views on Project Lombok, one way or the other.)

Before you use Project Lombok (or any other game-changing technology) in some project (open source or other wise), you need to make sure that the project stake holders agree to this. This includes the developers, and any important users (e.g. formal or informal sponsors).

You mention these potential issues:


Easy. Ignore / don't participate in the flamewars, or simply refrain from mentioning Lombok.

providing code snippets will confuse possible helpers,

If the project strategy is to use Lombok, then the possible helpers will need to get used to it.

people will complain about missing JavaDoc,

That is their problem. Nobody in their right mind tries to rigidly apply their organization's source code / documentation rules to third-party open source software. The project team should be free to set project source code / documentation standards that are appropriate to the technology being used.

(FOLLOWUP - The Lombok developers recognize that not generating javadoc comments for synthesized getter and setter methods is an issue. If this is a major problem for your project(s), then one alternative is to create and submit a Lombok patch to address this.)

and future commiters might just remove it all anyway.

That's not on! If the agreed project strategy is to use Lombok, then commiters who gratuitously de-Lombok the code should be chastised, and if necessary have their commit rights withdrawn.

Of course, this assumes that you've got buy-in from the stakeholders ... including the developers. And it assumes that you are prepared to argue your cause, and appropriately handle the inevitable dissenting voices.

share|improve this answer
What about in small open source projects? Your idea of the team agreeing is really good, but I'm also curious in the 1-2 person OS project point of view –  TheLQ Oct 4 '10 at 0:38
Same principle really, except that getting the agreement of one person (yourself) is a non-issue. I guess it might put off other possible project participants, but the kind of people who would be put off are probably not the kind of people you want anyway. Besides, they are hypothetical. –  Stephen C Oct 4 '10 at 0:49
I thing when he talks about missing JavaDoc, he means that getters and setters will not have JavaDoc, which is not very good. –  Denis Tulskiy Oct 4 '10 at 3:11
As a Lombok developer, I can say that generating javadoc is technically possible. Please participate in the google group if you've any bright ideas how to implement it. I mean, just generating a standard text is not that useful. Like getFoo, returns foo, setFoo sets the foo? How is that going to help? –  Roel Spilker Oct 4 '10 at 7:46
I'd say that javadoc for bean getters/setters does more harm than good. Those methods follow a well-understood convention that does not need to be added to the javadoc; that just adds to the noise. Only add documentation to getters and setters when they do something unexpected i.e. when they have side-effects. –  GaryF Oct 4 '10 at 11:20
show 2 more comments

Just started using Lombok today. So far I like it, but one drawback I didn't see mentioned was refactoring support.

If you have a class annotated with @Data, it will generate the getters and setters for you based on the field names. If you use one of those getters in another class, then decide the field is poorly named, it will not find usages of those getters and setters and replace the old name with the new name.

I would imagine this would have to done via an IDE plug-in and not via Lombok.

UPDATE After using Lombok for 3 months, I still recommend it for most projects. I did, however, find another drawback that is similar to the one listed above.

If you have a class, say MyCompoundObject.java that has 2 members, both annotated with @Delegate, say myWidgets and myGadgets, when you call myCompoundObject.getThingies() from another class, it's impossible to know if it's delegating to the Widget or Gadget because you can no longer jump to source within the IDE.

Using the Eclipse "Generate Delegate Methods..." provides you with the same functionality, is just as quick and provides source jumping. The downside is it clutters your source with boilerplate code that take the focus off the important stuff.

UPDATE 2 After 5 months, we're still using Lombok, but I have some other annoyances. The lack of a declared getter & setter can get annoying at times when you are trying to familiarize yourself with new code.

For example, if I see a method called getDynamicCols() but I don't what it's about, I have some extra hurdles to jump to determine the purpose of this method. Some of the hurdles are Lombok, some are the lack of a Lombok smart plugin. Hurdles include:

  • Lack of JavaDocs. If I javadoc the field, I would hope the getter and setter would inherit that javadoc through the Lombok compilation step.
  • Jump to method definition jumps me to the class, but not the property that generated the getter. This is a plugin issue.
  • Obviously you are not able to set a breakpoint in a getter/setter unless you generate or code the method.
  • NOTE: This Reference Search is not an issue as I first thought it was. You do need to be using a perspective that enables the Outline view though. Not a problem for most developers. My problem was I am using Mylyn which was filtering my Outline view, so I didn't see the methods. Lack of References search. If I want to see who's calling getDynamicCols(args...), I have to generate or code the setter to be able to search for references.

UPDATE 3 Learning to use the various ways of doing things in Eclipse I guess. You can actually set a conditional breakpoint (BP) on a Lombok generated method. Using the Outline view, you can right-click the method to Toggle Method Breakpoint. Then when you hit the BP, you can use the debugging Variables view to see what the generated method named the parameters (usually the same as the field name) and finally, use the Breakpoints view to right-click the BP and select Breakpoint Properties... to add a condition. Nice.

UPDATE 4 Netbeans doesn't like it when you update your Lombok dependencies in your Maven pom. The project still compiles, but files get flagged for having compilation errors because it can't see the methods Lombok is creating. Clearing the Netbeans cache resolves the issue. Not sure if there is a "Clean Project" option like there is in Eclipse. Minor issue, but wanted to make it known.

UPDATE 5 Lombok doesn't always play nice with Groovy, or at least the groovy-eclipse-compiler. You might have to downgrade your version of the compiler. Maven Groovy and Java + Lombok

UPDATE 6 A word of warning. Lombok is slightly addictive and if you work on a project where you can't use it for some reason, it will annoy the piss out of you. You may be better off just never using it at all.

share|improve this answer
Thanks I think this was the information the OP really wanted as opposed to a philosophical response. –  chaostheory Mar 1 '13 at 1:42
Thank you for updating this answer over time :) –  Twirrim Jul 31 '13 at 17:58
Bahaha UPDATE 6 is my favourite. –  Dylan Watson Jul 2 at 4:56
add comment

Go ahead and use Lombok, you can if necessary "delombok" your code afterwards http://projectlombok.org/features/delombok.html

share|improve this answer
+1 for delombok. –  fastcodejava Feb 2 '11 at 7:20
@fastcodejava when you say "+1 for x", x should be one of the points listed not the one and only point :) –  Kerem Baydoğan May 21 at 8:01
add comment

Personally (and therefore subjectively) I've found that using Lombok makes my code more expressive about what I'm trying to achieve when compared to IDE/own implementations of intricate methods such as hashcode & equals.

When using

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

it's much easier to keep Equals & HashCode consistent and keep track of which fields are evaluated, than any IDE/own implementation. This is especially true when you're still adding / removing fields regularly.

The same goes for the @ToString annotation and its parameters which clearly communicate the desired behavior regarding included / excluded fields, usage of getters or field access and wether or not to call super.toString().

And again by annotating an entire class with @Getter or @Setter(AccessLevel.NONE) (and optionally overriding any divergent methods) it's immediately clear what methods will be available for the fields.

The benefits go on and on..

In my mind it's not about reducing code, but about clearly communicating what you desire to achieve, rather than having to figure it out from Javadoc or implementations. The reduced code just makes it easier to spot any divergent-method implementations.

share|improve this answer
And to add to this: switching to Lombok has actually allowed to solve some intricate bugs in the past due to mismatched equals / hashCode implementations, and cases in which I forgot to update now-generated methods when a field was added. These potential benefits should be able to out balance most of the negatives you've mentioned. –  Tim Oct 4 '10 at 8:13
add comment

When I showed the project to my team the enthusiasm was high, so I think you should not be afraid of team response.

  • As far as ROI, it is a snap to integrate, and requires no code change in its basic form. (just adding a single annotation to your class)

  • And last, if you change your mind, you can run the unlombok, or let your IDE create these setters, getters, and ctors, (which I think no one will ask for once they see how clear your pojo becomes)

share|improve this answer
add comment

i have used Lombok almost all my projects for one year but unfortunately removed it. In the beginning it was a very clean way of development but setting up the development environment for new team members is not very easy and straightforward. When it comes to a headeche i just removed it. But it is a good work and needs some more simplicity to setting up.

share|improve this answer
can you elaborate on the headaches? –  Kevin Welker Sep 10 '12 at 16:10
The setup for Eclipse is extremely straightforward. Just "java -jar lombok.jar". –  Willie Wheeler Apr 16 at 19:01
I think the hardest part of setting up a new developer is realizing that you need to setup Lombok. There's no message saying "Lombok has not been setup" or anything like that. Instead you get weird messages like "setFoo" is not defined. If Lombok education is not part of your new developer on-board training process, then there will be major confusion. –  Snekse yesterday
add comment

I know I'm late, but I can't resist the temptation: anybody liking Lombok should also have a look at Scala. Many good ideas that you find in Lombok are part of the Scala language.

On your question: it's definitely easier to get your developers trying Lombok than Scala. Give it a try and if they like it, try Scala.

Just as a disclaimer: I like Java, too!

share|improve this answer
I like Scala and Lombok, but I can't see which ideas are you talking about. \@SneakyThrows, \@Data, ...? –  sinuhepop Aug 28 '13 at 22:26
@sinuhepop Generating getters and setters looks like Case Classes. The immutable-feature is Scala inherent and enriching APIs about your own methods is a built in Scala feature, too. –  sorencito Aug 29 '13 at 6:30
add comment

Wanted to use lombok's @ToString but soon faced random compile errors on project rebuild in Intellij IDEA. Had to hit compile several times before incremental compilation could complete with success.

Tried both lombok 1.12.2 and 0.9.3 with Intellij IDEA 12.1.6 and 13.0 without any lombok plugin under jdk 1.6.0_39 and 1.6.0_45.

Had to manually copy generated methods from delomboked source and put lombok on hold until better times.


The problem happens only with parallel compile enabled.

Filed an issue: https://code.google.com/p/projectlombok/issues/detail?id=613

share|improve this answer
add comment

I haven't tried using Lombok yet - it is/was next on my list, but it sounds as if Java 8 has caused significant problems for it, and remedial work was still in progress as of a week ago. My source for that is https://code.google.com/p/projectlombok/issues/detail?id=451 .

share|improve this answer
add comment

I'm not recommend it. I used to use it, but then when I work with NetBeans 7.4 it was messing my codes. I've to remove lombok in all of files in my projects. There is delombok, but how can I be sure it would not screw my codes. I have to spends days just to remove lombok and back to ordinary Java styles. I just too spicy...

share|improve this answer
add comment
