Why everyone should avoid Lombok

Lombok is utter crap. It’s an abomination. It’s a blight on software development.

And it is the opposite of object-oriented programming.

Lombok is clearly aimed at programmers who are accustomed to C, but:

• Java is not C.
• A Java bean is not a struct.
• If you have been writing property accessor methods that do nothing but read and write private fields, you’ve been doing it wrong.

Java bean properties are supposed to be encapsulated. This means the class is responsible for their validity.

Blindly setting private fields fails to do this.

Proper accessor methods

For instance:

public class Person {
    private String lastName;

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String name) {
        this.lastName = name;
    }
}

In the above code, there is no control on the lastName property. This forces other classes to check whether it’s null, whether it’s empty, whether it’s blank, etc.

We can save other users a lot of time by writing a contract, thus guaranteeing them the value is valid, so they don’t have to write any checks:

import java.util.Objects;

public class Person {
    private String lastName = "(unknown)";

    /**
     * Returns this person's last name.  The contract of this method is that
     * it will never return null, the returned value is never empty, and the
     * returned value will always contain at least one non-whitespace
     * character.
     *
     * @return this person's non-empty last name
     *
     * @see #setLastName(String)
     */
    public String getLastName() {
        return lastName;
    }

    /**
     * Updates this person's last name.  The argument must not be null,
     * and must contain at least one non-whitespace character.
     *
     * @param name new last name
     *
     * @throws NullPointerException if argument is null
     * @throws IllegalArgumentException if argument is empty or consists
     *                                  entirely of whitespace
     *
     * @see #getLastName()
     */
    public void setLastName(String name) {
        Objects.requireNonNull(name, "Last name cannot be null.");
        if (name.matches("\\s*")) {
            throw new IllegalArgumentException("Last name cannot be blank.");
        }
        this.lastName = name;
    }
}

Not only does this free other classes from having to do their own checks, reading generated javadoc is considerably faster than bringing up the source of the Person class and stepping through the internal code with one’s eyes.

No benefits

Lombok does not save any appreciable amount of time. Every IDE can generate accessor methods. Even if you’re a Luddite like me and prefer to write the methods by hand, it takes 5–10 minutes to do so for an average bean class.

At least, that’s how long it takes to write the equivalent of what Lombok does. What Lombok fails to do, is allow for javadoc on properties. Yes, writing javadoc for properties takes longer. As with all classes and all object-oriented development, the point of writing contracts is that the few minutes it takes to write it now, saves oneself and other developers hours of time later.

Using Lombok means javadoc isn’t even an option.

Then there’s Lombok’s annotations for generating equals(Object) and hashCode() methods. By default, these consider a bean’s identity to be based on all of its properties, which is almost always the wrong behavior. Only short value classes will want to base their identity on all of their properties—and, well, they’re short anyway, so there is minimal gain, but a significant penalty: cryptic pseudo-code that can’t be traced with a debugger.

In fact, all of the Lombok generated methods cannot be traced by a debugger or examined if they’re part of a stack trace.

There is no good reason to be using Lombok and everyone should avoid it like the plague.