Spring Boot with Lombok

Yes. Lombok only runs while your code is compiled. The compiled classes contain ordinary Java methods, and Lombok itself is not part of the running application or the packaged JAR.

It is widely used in production systems of all sizes. The real risks are in how it is used, such as @Data on JPA entities, not in Lombok itself.

The compiler did not run Lombok, so methods such as getName() were never generated. Check:

1. Maven build fails: add Lombok to annotationProcessorPaths in the compiler plugin. Newer JDK versions no longer run annotation processors found on the classpath automatically.
2. Only the IDE shows errors: enable annotation processing in the IDE, or install Lombok support for Eclipse.
3. After a Java upgrade: the Lombok version may be too old for the new JDK. Upgrade Spring Boot or Lombok.

Lombok works closely with the Java compiler’s internals, so each new Java release needs a Lombok release that supports it. Support usually arrives around the time the new Java version is released.

When upgrading Java:

• Upgrade Spring Boot first; it manages a matching Lombok version for you.
• If you need a newer Lombok, set the lombok.version property in pom.xml.
• Watch for build errors that mention Lombok or annotation processing, which signal an outdated version.

By default, Lombok does not copy @Qualifier from a field to the generated constructor parameter, so Spring ignores it. Tell Lombok to copy it, in lombok.config:

lombok.copyableAnnotations += org.springframework.beans.factory.annotation.Qualifier

@Service
@RequiredArgsConstructor
public class AlertService {

    @Qualifier("smsNotifier")
    private final Notifier notifier;   // now injected with the "smsNotifier" bean
}

Without this setting, Spring may fail with an error about several candidate beans of the same type.

A class with only @Builder has no public no-argument constructor and no setters, so Jackson does not know how to create it. Two fixes:

// Option 1: let Jackson use the builder (recommended)
@Value
@Builder
@Jacksonized
public class CreateOrderRequest {
    String customerEmail;
    List<String> items;
}

// Option 2: add the constructors Jackson and other tools expect
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class CreateOrderRequest { ... }

@Jacksonized configures Jackson to deserialize through the builder, so the class can stay immutable.

The builder sets every field from its own internal values. A field the builder did not set is given null, 0 or false, which overwrites your default:

@Builder
public class Settings {
    private int pageSize = 20;                // ignored by the builder: becomes 0

    @Builder.Default
    private String theme = "light";           // kept when theme() is not called
}

Add @Builder.Default to every field with a default value. Lombok warns about this at compile time, so watch for that warning.

The last row surprises people: Lombok removes the is prefix, and Jackson then writes the JSON property as active, not isActive. Name boolean fields without the is prefix to avoid confusion.

Use it rarely. @SneakyThrows lets a method throw a checked exception without declaring it. That hides important information from callers, who no longer see that the method can fail with, for example, an IOException.

// Prefer: wrap the checked exception in a meaningful unchecked one
public String readTemplate(Path path) {
    try {
        return Files.readString(path);
    } catch (IOException ex) {
        throw new TemplateLoadException("Could not read " + path, ex);
    }
}

Acceptable uses are narrow, such as inside lambdas where a checked exception truly cannot occur.

Both are annotation processors, and MapStruct must see the methods Lombok generates. Register both, plus a small binding library that makes them cooperate:

<annotationProcessorPaths>
    <path>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>${lombok.version}</version>
    </path>
    <path>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok-mapstruct-binding</artifactId>
        <version>0.2.0</version>
    </path>
    <path>
        <groupId>org.mapstruct</groupId>
        <artifactId>mapstruct-processor</artifactId>
        <version>${mapstruct.version}</version>
    </path>
</annotationProcessorPaths>

Without the binding, MapStruct may report that it cannot find getters or setters that Lombok was supposed to generate.

Yes. Put @Getter or @Setter on individual fields instead of the class, or put them on the class and switch them off for particular fields:

@Getter
public class Employee {

    private String name;
    private String department;

    @Getter(AccessLevel.NONE)
    private BigDecimal salary;      // no public getter: exposed only through business methods

    public boolean earnsMoreThan(BigDecimal amount) {
        return salary.compareTo(amount) > 0;
    }
}

Hiding fields this way keeps sensitive data inside the class and encourages meaningful methods instead of raw getters.

Some of them, yes. Records already have constructors, accessors, equals, hashCode and toString, but Lombok can still add a builder or with methods:

@Builder
@With
public record ShippingAddress(String street, String city, String postcode) {
}

ShippingAddress home = ShippingAddress.builder()
        .street("12 MG Road").city("Bengaluru").postcode("560001")
        .build();

ShippingAddress office = home.withStreet("45 Brigade Road");

Annotations such as @Getter, @Setter or @Data make no sense on records, because records are immutable and already have accessors.

Generated methods have no source lines, so you cannot place a breakpoint inside, say, a generated getter. Practical options:

• Put a field watchpoint on the field itself. The debugger stops whenever it is read or changed, including through generated methods.
• Write that one method by hand. Lombok skips generating any method you write yourself, so you can debug it normally.
• Delombok the class temporarily to see and step through the full code.

When a class extends another, Lombok by default compares only the subclass’s own fields, and warns about it. callSuper = true includes the parent’s equals() and hashCode() too:

@EqualsAndHashCode
public class Vehicle {
    private String registration;
}

@EqualsAndHashCode(callSuper = true)
public class Truck extends Vehicle {
    private int maxLoadKg;
}

Without it, two trucks with different registrations but the same load would be considered equal. If the parent class is Object, leave callSuper off.

It makes setters return this, so you can chain calls:

@Getter
@Setter
@Accessors(chain = true)
public class SearchFilter {
    private String keyword;
    private int page;
}

SearchFilter filter = new SearchFilter().setKeyword("lamp").setPage(2);

It is convenient, but some libraries expect setters that return void, following the JavaBeans convention, and may not recognise chained setters as properties. For readable object creation, @Builder is usually the safer choice.

Not hard. Lombok has a delombok tool that rewrites your source code into plain Java, with all the generated methods written out. Run it once, review the result, remove the Lombok dependency, and the project continues as normal Java code.

This low exit cost is one reason many teams are comfortable adopting Lombok: it is a convenience, not a lock-in.

Common reasons:

• Hidden code: some developers prefer seeing every method in the source file.
• Build coupling: Lombok depends on compiler internals, so Java upgrades may have to wait for a Lombok update.
• Modern Java covers much of it: records replace many data classes, and IDEs can generate the remaining methods.
• Easy to misuse: @Data on entities or setters everywhere can cause real bugs.

Neither choice is wrong. What matters is that a team agrees on one approach and applies it consistently.

Use @NotNull on request DTOs so clients get a clear 400 response, and @NonNull to catch mistakes inside your own code early.

Usually not. @Cleanup closes a resource at the end of its scope, but Java’s built-in try-with-resources does the same job, is understood by every developer and tool, and handles exceptions during closing more carefully:

try (BufferedReader reader = Files.newBufferedReader(path)) {
    return reader.lines().count();
}   // reader is closed automatically, even if an exception occurs

Prefer standard Java features when they are just as short. Use Lombok for things Java does not offer as conveniently, such as builders and constructor injection.

Yes. @Slf4j creates an SLF4J logger, and SLF4J is only an interface. It sends log messages to whichever logging library is on the classpath: Logback, which is Spring Boot’s default, or Log4j2 if you switch to spring-boot-starter-log4j2.

Lombok also offers annotations for using a specific library directly:

Stick with @Slf4j, so you can change the logging library later without touching any class.

Slightly. Lombok runs as part of every compilation, which adds a small amount of time. For typical Spring Boot projects the difference is hardly noticeable.

In very large codebases, keep Lombok up to date, because newer versions include performance improvements. The running application is not affected at all, because Lombok’s work is finished once the classes are compiled.