Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Why the lazy coder in you would enjoy Project Lombok

Screenshot 2014-02-25 10.23.29 copy

I enjoy discovering and writing about software, especially when it brings cool productivity gains for coders who care about that sort of thing (i.e. geeks). Recently I felt inspired to revisit Project Lombok–have you ever heard of it? It’s a nice island in Indonesia, known for it’s beaches and perfect for relaxing.

But if you want give your fingers a break and enjoy a little relaxation away from the boilerplate, there is another Lombok out there that you might want to check out. Project Lombok is boilerplate code generator, but it’s not terribly new–aside from being a cool tool with ghastly website, it was introduced in mid-2009 and has seen more or less regular updates since 2011. But most devs have never heard of it (please do our little poll below). Just more evidence that even cool tools and technologies don’t exactly go viral among developers, even those active in JUG communities.

It’s a nifty little piece of software and if you do Java, I recommend that you use it. Any devs out there using Spring Roo or something similar will know what I mean. But if you selected “A” above, then here’s a short intro to Lombok.

Lombok is a tool that generates code for you, but not in the way that your IDE generates it. Your IDE generates getters & setters, or equals and more, and then puts the code in your uncompiled class file. Lombok generates the same thing, but does it in the class file; all you need to do is add some annotations like @Setter, @Getter, @Builder, @Data … to your code and Lombok generates the setters, getters and so on for you. At the same time, you can override whatever is generated by just writing the method yourself instead.

We don’t need to go into details about how to use it–there are enough Lombok guides out there and the Lombok site, along with the GitHub repo, is good enough at explaining everything. Let’s go into the why you should use it!

For starters, it’s easy for the lazy coder in you. Just add @Data and you have getters, setters, equals, hashcode, toString in your pojo. Of course, you could argue here that their IDE can do that too. Why would you need another tool to do it? It’s a fair question, with an even fairer answer.

Here’s what it would look like using your IDE to add the code to the file, while you write the members and generate the methods:

public class JRebel {
	private int reloads;
	private long timeSaved;
	public int getReloads { return reloads;}
	public setReloads(int reloads) { this.reloads = reloads; }
	public long getTimeSaved{ return timeSaved;}
	public setTimeSaved(long timeSaved) { this.timeSaved = timeSaved; }

In case you need a default equals, hashcode or toString, etc, your class would get longer and longer. The more members in your class, the more you have to scroll in your IDE to know what is happening (or click a method to see it’s internals.) But when you use Lombok, you can ditch the boilerplate and keep your class short, concise and, most of all, very readable:

public class JRebel {
	private int reloads;
	private long timeSaved;

And it’s just great! KISS. And that’s not all: How many Builder patterns have you written for beans? Probably too many! Here you can use @Builder, which generates a static builder class for your bean. These days, I can’t live without this anymore, and not only because it does work for me.

Lombok can’t handle Builders when you’re extending from other classes. And actually this is great, since it enforces you to use composition over inheritance. I have no idea if this was done on purpose or by accident, but it should stay like that.

Not only can I use Lombok for simple pojo beans, but also for service classes and such. However, there is DI everywhere now (be it with Spring, Guice or real Java CDI), and for unit testing purposes you don’t always want to start your CDI container. Lombok let’s you just have a setter (or constructor) for all that has to be injected.

But it’s not all gravy. On the downside, refactoring can be a bit of work. Changing a member name always has effect on generated getters, setters and builders. But let me give you a tip: for the getters and setters it’s not so difficult to overcome. First, add the real getter and setter in your Java file then refactor the class member’s name, and then the methods. Done, piece of cake. But then again, you should be programming an interface, not an implementation, in which case you’d refactor the interface method name and not the implementation one.

One last thing: thanks to Lombok, it becomes really easy to write your transfer objects between the different layers of your application and give each of them their own decoupled API without actually needing to write a lot of pojo boilerplate code.

Needless to say, Lombok saves me some extra typing by generating some code in class files, while keeping your code as succinct as possible. It’s perfect for the lazy coder in you, and it might be better known if it was included in the JDK, rather than existing as an extension that seemingly few developers have heard of, and fewer even still talk about. If you’ve used Lombok before, or have any cool tips, leave comments below tweet me @Redlabbe (or on @RebelLabs).

Tools & technologies that boost your productivity rock. See what 1000 developers told RebelLabs in our 2013 Developer Productivity Report about how the tools they use and methodologies they practice affect the quality and predictability of their software releases. Warning: disruptive findings inside!

Download the PDF

  • ikk

    I hope Java 9 (or 10…) brings Lombok-like features out-of-the-box.

  • Adil

    Properties with Lombok would be perfect

  • balder

    Can you elaborate on what you mean exactly?

  • OctavianNita

    He probably means that it would be perfect to have Lombok(-like) properties natively in Java… honestly, I’ve never understood why Oracle / Java gods decided is was more valuable or at least easier to add underscores in numeric literals and binary literals rather than creating Lombok-like features…

    How often does one write (or really need) binary literals or large magic constants in code? (I understand the main reason for such features was readability) Now, how often does one create domain models full of necessary entity properties?

    Also, it couldn’t have been so complicated to add these kinds of features — Project Lombok was around before Java 7…

  • balder

    FYI ! now, the intellij plugin has initial support for some cool lombok and delombok refactoring actions

  • Morten Christensen

    Lombook is interesting but I find it a bit risky to use with all the magic going on where you can run into integration problems now or in the future. For example I read there is a problem with the latest JDK. I also find Lambook not customizable enough. So I just released an alternative annotation processor for generating (custom) value objects from Interfaces which I think have a couple of benefits over Lombook. First of all it uses standard java 8 APIs only so it integrates with all java tools and JDK’s without problems. It is also extremely customisable so you can modify and extend the value objects with extra generated functionality. Want your own cached hashCode or a custom generated method method inserted. No problem. You can check my take on this at “”. Let me know what you think?

  • asdf

    Oh, cool, another abstraction layer for Java…