Kodumaro :: Why Lombok is a waste of time

Released on January 23rd, 2019
The shadows behind the code.
Java

I’ve recently started working with Lombok, a really great project.

The Lombok’s goal is to add facilities and syntax sugar to a bureaucratic and painful Java language, and at first sight it seems very useful.

Let’s look at a made-easier Java code. First without Lombok (I’m suppressing the imports):

class Person {
    private final String name;
    private final String surname;
    private final Date birth;
    public Person(String name, String surname, Date birth) {
        this.name = name;
        this.surname = surname;
        this.birth = birth;
    }
    public String getName() {
        return this.name;
    }
    public String getSurname() {
        return this.surname;
    }
    public Date getBirth() {
        return this.birth;
    }
    public boolean equals(Object o) {
        if (o == this) return true;
        if (!(o instanceof Person)) return false;
        final Person other = (Person) o;
        return other.getName() == getName()
            && other.getSurname() == getSurname()
            && other.getBirth() == getBirth();
    }
    public String toString() {
        return "Person(name=" + getName()
            + ", surname=" + getSurname()
            + ", birth=" + getBirth()
            + ")";
    }
}

And a lot of other methods you may want.

Now the same code using Lombok:

@Value
class Person {
    private final String name;
    private final String surname;
    private final Date birth;
}

It looks wonderful!

We can do many other things, like change:

final HashMap<String, Integer> map = new HashMap<>();

By:

val map = new HashMap<String, Integer>();

So… what’s wrong with Lombok?

Let’s take a look at Scala. The very same Person class:

case class Person(name: String, surname: String, birth: Date)

That simple, using the native language resources, no twists or juggling.

The keyword here is “native”. Lombok injects a lot of annotations and strains into Java to do what Scala already does easily. The val is a Scala token yet, just as var.

For every Lombok feature, there’s a native Scala one – simpler, clearer.

Perhaps someone says that Lombok is Java yet, and Scala must be compiled to Java code before the bytecode, but even so it’s not fully honest, because the Lombok code needs to be compiled to Java code too, so it doesn’t find grounds.

If you’re thinking of Lombok as solution, remember there are no excuses that justify using Lombok instead of Scala, and think twice.

Update: I just found out that NetBeans doesn’t work well with Lombok… 😓

You’re forced to use Eclipse.


Also in Medium.

Career | Java

DEV Profile 👩‍💻👨‍💻