Lombok @Data and Final Fields: Solving the “Default Constructor in Base Class” Error

1. Introduction

When working with Lombok, the @Data annotation is a popular choice because it generates boilerplate code like getters, setters, toString(), equals(), hashCode(), and constructors automatically.

However, things can get tricky when we combine Lombok with inheritance. Specifically, if a subclass annotated with @Data extends an abstract base class that contains final fields, we may encounter the error:

lombok needs a default constructor in the base class

In this tutorial, we’ll explore why this error happens, walk through examples that reproduce the problem, and demonstrate the solution to fix it.

2. Understand the Problem

Let’s start with an abstract base class:

public abstract class BaseEntity {
    private final String createdBy;

    protected BaseEntity(String createdBy) {
        this.createdBy = createdBy;
    }

    public String getCreatedBy() {
        return createdBy;
    }
}

In this design, the field createdBy is declared as final, which means it must always be assigned a value when the object is constructed and cannot be reassigned later. To enforce this rule, the class only provides a constructor that accepts a createdBy argument.

Since no no-argument (default) constructor is provided, every subclass is required to supply this value explicitly whenever it calls the base class constructor.

Now consider what happens when we create a subclass and annotate it with Lombok’s @Data:

@Data
public class User extends BaseEntity {
    private String name;

    public User(String createdBy, String name) {
        super(createdBy);
        this.name = name;
    }
}

At this point, compilation fails with the error message:

lombok needs a default constructor in the base class

The error happens because @Data generates a constructor that expects the base class to have a no-argument constructor. When the base class contains final fields but doesn’t define such a constructor, Lombok cannot properly chain constructors. Since Java requires every subclass constructor to call one of its parent constructors, the generated code becomes invalid, and compilation fails.

3. Use @NoArgsConstructor(force = true)

To resolve this problem, one approach is to use Lombok’s @NoArgsConstructor annotation with the force = true option on the base class. This tells Lombok to generate a no-argument constructor that initializes final fields with default values such as null, 0, or false:

@NoArgsConstructor(force = true)
public abstract class BaseEntity {
    private final String createdBy;

    public BaseEntity(String createdBy) {
        this.createdBy = createdBy;
    }
}

By doing this, Lombok ensures that the subclass can compile because the required default constructor is now available. However, this approach may not always be safe, since it allows final fields to start with meaningless default values.

4. Provide an Explicit Default Constructor

A safer alternative is to explicitly define a default constructor in the base class ourselves. This constructor can assign a sensible default value to the final field, ensuring that the object is in a valid state even when created with no arguments:

public abstract class BaseEntity {
    private final String createdBy;

    protected BaseEntity() {
        this.createdBy = "system";
    }

    protected BaseEntity(String createdBy) {
        this.createdBy = createdBy;
    }
}

In this case, any subclass that doesn’t provide a value for createdBy will automatically use “system” as the default. This approach is preferable in scenarios where we want to maintain meaningful defaults for our domain model.

5. Avoid @Data and Use Targeted Annotations

Another solution is to avoid using the @Data annotation altogether and instead use more targeted Lombok annotations such as @Getter and @Setter. This gives us more control over which methods Lombok generates while preventing it from creating problematic constructors:

@Getter
@Setter
public class User extends BaseEntity {
    private String name;

    public User(String createdBy, String name) {
        super(createdBy);
        this.name = name;
    }
}

In this example, the User class remains clean and concise while avoiding the pitfalls of @Data constructor generation.

6. Real-World Example with JPA Entities

This problem commonly arises in Spring Boot applications that use JPA. A typical pattern is to define a BaseEntity class that stores auditing information, such as createdAt or createdBy:

public abstract class BaseEntity {
    @Column(nullable = false, updatable = false)
    private final LocalDateTime createdAt;

    protected BaseEntity() {
        this.createdAt = LocalDateTime.now();
    }
}

A User entity might then extend this base class:

@Data
@Entity
public class User extends BaseEntity {
    @Id
    @GeneratedValue
    private Long id;
    private String username;
}

By explicitly providing a default constructor in the base class, the error is resolved, and the entity works correctly with both Lombok and JPA.

7. Conclusion

In this article, we explored why Lombok shows the “lombok needs a default constructor in the base class” error when a subclass uses @Data, but the parent has final fields without a no-args constructor. We also covered simple fixes, like adding a default constructor, using @NoArgsConstructor(force = true), or switching to targeted Lombok annotations.