Lombok: کدِ کمتر، باگِ کمترLombok: Less Boilerplate, Fewer Bugs

Let's start with a truth anyone who has written Java for a few months has felt in their bones: Java is a verbose language. Just to say "a user has a name and an email," you write the fields, then a getter and setter for each, then equals, hashCode, toString, and a constructor or two. A class whose idea is two lines becomes fifty on screen — and those fifty lines aren't just tedious, they're dangerous: forget one field in hashCode and you'll spend nights hunting a silent bug.

Lombok was built to cure exactly this pain. In this chapter you won't just memorize a list of annotations — you'll understand what code each one generates, how that generation actually happens inside the compiler, where the magic turns into a trap, and how to talk about it in a senior interview so it's clear you're not just a user but someone who knows what's happening under the hood.

Part 0 — a few words you must feel before we start

Before any code, three terms recur throughout this chapter. Let me plant them now.

• Boilerplate: code you have to write but that contains no new logic — getters, setters, constructors. The name comes from pre-printed newspaper plates where only the name was swapped. Boilerplate is bad not because it's long, but because it's the wrong place: every hand-written line is a chance for a bug.
• Annotation: a metadata label on your code, like @Override. It has no behavior itself; it's just a note on a class/field/method that other tools can read and act upon.
• Bytecode and the AST: the compiler (javac) first turns your code into an in-memory structural tree called the AST (Abstract Syntax Tree), then generates bytecode (.class) from that tree, which the JVM runs. Hold onto this sentence; Lombok's entire secret lives in that "tree."

Why Lombok at all? See the pain in code

Let's hand-write a perfectly ordinary data class — a user with three fields, written "correctly":

public class User {
    private final Long id;
    private String name;
    private String email;

    public User(Long id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    public Long getId() { return id; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        User user = (User) o;
        return Objects.equals(id, user.id)
            && Objects.equals(name, user.name)
            && Objects.equals(email, user.email);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, name, email);
    }

    @Override
    public String toString() {
        return "User{id=" + id + ", name='" + name + "', email='" + email + "'}";
    }
}

Nearly forty lines, and the idea was simply "a user with three fields." Now the same with Lombok:

import lombok.Data;

@Data
public class User {
    private final Long id;
    private String name;
    private String email;
}

Five lines. The point isn't that it's shorter; the point is that the hand-written version was error-prone and this one isn't. If tomorrow you add a phone field, the hand-written version requires you to remember to add it to equals, hashCode, toString, and the constructor — and it's exactly that "remember" that breeds bugs. Lombok keeps them all in sync automatically.

Wire up Lombok

Lombok isn't an ordinary library you call at runtime; it works only at compile time. That's why its scope matters.

In Maven:

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.46</version>
    <scope>provided</scope>
</dependency>

In modern Gradle, the correct form declares it both as an annotationProcessor and compileOnly:

dependencies {
    compileOnly 'org.projectlombok:lombok:1.18.46'
    annotationProcessor 'org.projectlombok:lombok:1.18.46'
}

The magic under the hood: how Lombok really works

This is the part that separates seniors from juniors. Many people say "Lombok is an annotation processor." That's half true and wrong on the key point. Let's be precise.

Java has an official API called Annotation Processing (javax.annotation.processing). With it, a processor can inspect annotations and generate new files — say, a brand-new class. But this API has a deliberate limitation: it does not let you modify an existing class. You cannot use the official API to inject the getName method inside the existing User class. And that's exactly what Lombok wants to do.

So what does Lombok do? It registers itself as an annotation processor so it gets invoked during compilation, then pulls a trick: instead of generating a new file, it casts the objects the compiler hands it to internal, private javac types (like com.sun.tools.javac.tree.JCTree). Those objects are the compiler's actual AST, not copies. Lombok mutates that tree directly — it plants the getter method inside the class node. From there the compiler carries on and produces bytecode as if you'd written that method yourself.

For Eclipse the story differs slightly: there Lombok injects itself as a Java agent into the Eclipse compiler (ecj) and performs the same AST manipulation. In both cases the end result is identical: a clean .class with zero runtime dependency on Lombok.

The core annotations, one by one

@Getter and @Setter

The simplest ones. They go on a field or on the whole class:

import lombok.Getter;
import lombok.Setter;

@Getter @Setter
public class Account {
    private Long id;
    private String owner;
    @Setter(AccessLevel.NONE)   // getter only, no setter
    private BigDecimal balance;
}

@Getter on the class means "generate a getter for every field." You can control the access level (AccessLevel.PROTECTED) or turn off one with AccessLevel.NONE. For a boolean isActive it correctly generates isActive(), not getIsActive().

@ToString and @EqualsAndHashCode

@ToString
@EqualsAndHashCode
public class Point {
    private int x;
    private int y;
}

@ToString produces a readable form like Point(x=3, y=4). @EqualsAndHashCode generates both methods together and in sync — and that "together" matters: Java's contract says equal objects must have equal hash codes, and because Lombok derives both from the same set of fields, that contract never breaks.

You can control the fields:

@ToString(exclude = "password")
@EqualsAndHashCode(of = {"id"})
public class User {
    private Long id;
    private String username;
    private String password;   // in neither toString nor equals
}

@Data — the full bundle

@Data is the popular shortcut: it bundles five annotations at once.

So @Data is great for a mutable DTO or data object. But that very "all fields" becomes our main trap later in the JPA section; hold onto it.

Constructors: three annotations

• @NoArgsConstructor — a no-argument constructor (required by frameworks that build objects via reflection, like JPA and Jackson).
• @AllArgsConstructor — a constructor with all fields.
• @RequiredArgsConstructor — a constructor only for "required" fields: every uninitialized final field, and every @NonNull field.

The most common use of @RequiredArgsConstructor is dependency injection in Spring:

@Service
@RequiredArgsConstructor
public class OrderService {
    private final OrderRepository repository;
    private final PaymentGateway payment;

    // Lombok generates
    // OrderService(OrderRepository, PaymentGateway)
    // and Spring uses it for constructor injection.
}

@Value — the immutable sibling

If @Data is "mutable," @Value is its immutable twin. A @Value:

• makes the class final,
• makes every field private final,
• generates getters but no setters,
• generates equals/hashCode/toString and an all-args constructor.

import lombok.Value;

@Value
public class Money {
    Currency currency;   // no need to write private final; it's added for you
    BigDecimal amount;
}

This is effectively the "value object" concept — which raises the big question: how does it differ from a Java record? We'll get there.

@Builder — the builder pattern without the pain

When a class has several optional fields, a constructor with ten arguments is a nightmare (new Pizza(true, false, null, 12, ...) — which is which?). The Builder pattern solves this, and @Builder gives it to you for free:

import lombok.Builder;

@Builder
public class Pizza {
    private String size;
    private boolean cheese;
    private boolean pepperoni;
    private int slices;
}

// usage:
Pizza p = Pizza.builder()
        .size("large")
        .cheese(true)
        .slices(8)
        .build();

Readable, safe, order-free. But it has a very famous trap:

@Builder.Default
private int slices = 8;   // now the default really is 8

Two useful companions of @Builder:

• @Singular on collection fields: enables builder.topping("cheese").topping("basil") and makes the final collection immutable.
• @Jacksonized (alongside @Builder) makes the builder deserializable by Jackson; recent versions support both Jackson 2 and Jackson 3.

@Slf4j and the logging family

Writing this line in every class is itself boilerplate:

private static final Logger log = LoggerFactory.getLogger(OrderService.class);

@Slf4j generates exactly that and hands you a ready log field:

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class OrderService {
    public void place(Order o) {
        log.info("placing order {}", o.getId());
    }
}

Its siblings: @Log4j2, @CommonsLog, @JBossLog, and @Log (java.util.logging). In practice @Slf4j is the industry standard because SLF4J is a facade that keeps the implementation (Logback/Log4j2) decoupled.

The finer tools

val and var

val means "a final local variable whose type you infer," and Lombok's var is the same without final:

val names = new ArrayList<String>();   // type: ArrayList<String>, and final

An important historical note: native var arrived in Java 10 (it's not java.lang.var — it's a reserved type name of the language). So today Lombok's var is nearly useless, and Lombok's val can be replaced by native final var. This is a good example of how the language gradually absorbs Lombok's features.

@NonNull

public void setName(@NonNull String name) {
    this.name = name;   // Lombok injects a null-check at the start of the method
}

If you pass null, a NullPointerException with a clear message is thrown — instead of blowing up a few lines later in some confusing place. It also works on constructor parameters.

@SneakyThrows — lovely and dangerous

Java forces you to either catch checked exceptions or declare them in the method signature. Sometimes that's annoying, e.g. when you know the error effectively can't happen:

import lombok.SneakyThrows;

@SneakyThrows
public String readConfig() {
    return Files.readString(Path.of("config.txt"));  // throws IOException, but we don't declare it
}

@Cleanup

Automatic resource management without writing try-with-resources:

@Cleanup InputStream in = new FileInputStream("data.bin");
// at the end of scope, Lombok calls in.close() for you

Now that try-with-resources is native, this is less needed, but it stays useful for resources that aren't AutoCloseable.

The big trap: Lombok and JPA/Hibernate

This is the most practical part of the chapter. @Data on a DTO is harmless, but @Data on a JPA entity is a minefield. Three disasters:

1) The all-fields equals/hashCode disaster. Entities are identified by their primary key (id), but that id is often null until the moment it's saved to the database. Watch this scenario:

@Entity
@Data   // ← disaster
public class Product {
    @Id @GeneratedValue
    private Long id;
    private String name;
    private BigDecimal price;
}

Set<Product> set = new HashSet<>();
Product p = new Product();     // id is still null
set.add(p);                    // lands in a bucket based on the current hashCode
repository.save(p);            // now id gets a value → hashCode changes!
set.contains(p);               // false! it looks in the wrong bucket

hashCode must not change during an object's lifetime, but @Data makes it depend on all fields, and the id changes mid-flight. Result: the entity gets lost in a HashSet/HashMap.

2) The lazy-loading and StackOverflow disaster in toString. Suppose you have a bidirectional relationship: an Order has a list of items, and each OrderItem refers back to its order. @Data generates toString for both, printing the fields → Order.toString() walks into items, which walks back into order, and... StackOverflowError. Worse: calling toString or hashCode on a lazy @OneToMany collection fetches the entire relationship from the database — an unwanted heavy query, possibly outside a transaction (LazyInitializationException).

3) The proxy problem. Hibernate builds a proxy of your entity object for lazy loading. If the generated equals checks getClass(), then proxy.getClass() != Product.class and the comparison comes out wrong.

@Entity
@Getter @Setter
@ToString(onlyExplicitlyIncluded = true)
@EqualsAndHashCode(onlyExplicitlyIncluded = true)
public class Product {

    @Id @GeneratedValue
    @EqualsAndHashCode.Include
    @ToString.Include
    private Long id;

    private String name;      // in neither equals nor hashCode
    private BigDecimal price;

    @ToString.Exclude
    @OneToMany(mappedBy = "product")
    private List<Review> reviews;   // kept out of toString so it isn't lazy-loaded
}

lombok.config — project-wide policy

You can drop a lombok.config file at the project root to tune Lombok's behavior for all files at once. The system is "bubbling": a parent directory's settings apply to child directories unless overridden.

# the config tree root is here; don't look higher
config.stopBubbling = true

# put @lombok.Generated on every generated member
# (so coverage tools like JaCoCo ignore them)
lombok.addLombokGeneratedAnnotation = true

# warn if callSuper wasn't set explicitly
lombok.equalsAndHashCode.callSuper = warn

# ban @Data across the whole project (policy enforcement)
lombok.data.flagUsage = error

delombok — see the real code, and the way out

delombok takes your source code and produces a version where all Lombok annotations are expanded — that is, @Getter becomes the actual getter method. Two main uses:

1. See exactly what Lombok generated — great for learning and debugging.
2. Exit strategy — if one day you want to remove Lombok from a project, delombok generates the equivalent Lombok-free code, and you can commit that. It's a solid answer to the worry "what if we get locked into Lombok?"

java -jar lombok.jar delombok src/main/java -d target/delomboked

Criticisms: when not to reach for Lombok

Lombok is popular but not beyond criticism. A senior should know both sides:

• Reliance on internal APIs. That com.sun.tools.javac back window has broken repeatedly across JDK upgrades. This is a structural risk.
• Invisible magic. Code you don't see is harder for a new teammate to understand. "Where did getName come from?"
• Tooling dependence. Without the IDE plugin the experience is broken; static-analysis tools and other annotation processors sometimes clash with Lombok (processor ordering).
• Harder debugging. Stepping through generated code is murky.
• Easy to misuse. @Data everywhere, @SneakyThrows where it doesn't belong, setters that destroy immutability.

Records vs Lombok

Java 16 finalized records, and the question came up immediately: "so we don't need Lombok anymore?" The precise answer: in part of Lombok's territory, yes; in the rest, no.

// a native Java record — no library at all
public record Money(Currency currency, BigDecimal amount) {}

This record itself generates private final fields, a constructor, accessors (as amount(), not getAmount()), and equals/hashCode/toString — exactly @Value's territory.

An important note: records and Lombok can coexist. For instance, @Builder works on a record, and so does @Slf4j. So you don't have to abandon one entirely.

A few best practices to keep in mind

• On DTOs, freely use @Data/@Builder.
• On entities, never @Data/@Value; only @Getter/@Setter + equals/hashCode with onlyExplicitlyIncluded on the id.
• For Spring services, @RequiredArgsConstructor + final fields.
• For a simple value object, consider record first, then @Value.
• Turn on lombok.addLombokGeneratedAnnotation = true.
• Don't forget @Builder.Default for every field with a default value.
• Use @SneakyThrows only where it genuinely makes sense.
• When upgrading the JDK, update Lombok first.

Interview Questions