LearnAI ToolsCareerPractice BuildsPlayContact
Lesson 1719 min read

DevTools & Developer Experience Dependencies

Cover spring-boot-devtools for automatic restarts, Lombok for eliminating boilerplate, and spring-boot-configuration-processor for IDE autocomplete on custom properties.

Introduction

None of the dependencies in this lesson change what your application does in production — all three exist purely to make the day-to-day experience of writing and running Spring Boot code faster and less repetitive. That is exactly why each of them is scoped to stay out of your production artifact.

What You Will Learn
  • How spring-boot-devtools restarts your app automatically as you save code changes.
  • Why devtools is marked optional/developmentOnly and never ships to production.
  • How Lombok's @Data and @Builder eliminate getter, setter, and constructor boilerplate.
  • How spring-boot-configuration-processor gives you IDE autocomplete on your own custom properties.

spring-boot-devtools

Without devtools, changing a single line of Java means stopping the app, waiting for Maven to rebuild, and starting it again. With devtools on the classpath, saving a change triggers an automatic restart — much faster than a cold JVM start because unchanged classes are not reloaded.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <optional>true</optional>
</dependency>
optional=true and developmentOnly

The optional flag (or Gradle's developmentOnly configuration) prevents devtools from being pulled in transitively by anything that depends on your project — and Spring Boot's Maven and Gradle plugins already exclude it from the final packaged jar automatically. You do not need to remove it before deploying; it is designed to disappear on its own.

Devtools also disables template caching for engines like Thymeleaf during development, so an edited HTML template shows up on browser refresh without a restart at all — this is often called live reload when paired with the optional LiveReload browser extension.

Lombok: Eliminating Boilerplate

A typical Java DTO needs a constructor, getters, setters, equals(), hashCode(), and toString() — dozens of lines that add no real logic. org.projectlombok:lombok generates all of it at compile time from a handful of annotations, so the source file stays focused on the fields that actually matter.

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <optional>true</optional>
</dependency>
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class Product {
    private String id;
    private String name;
    private double price;
}


// usage elsewhere
Product product = Product.builder()
    .id("p1")
    .name("Keyboard")
    .price(49.99)
    .build();


System.out.println(product);
What @Data Generates

Click Run to see what this code prints.

IDE Support Required

Lombok works by modifying bytecode at compile time via an annotation processor, which means your IDE needs the Lombok plugin installed (built into IntelliJ IDEA via a bundled plugin, a separate install for Eclipse/VS Code) or it will show phantom "method does not exist" errors even though the code compiles and runs fine.

Configuration Processor: IDE Autocomplete

Spring Boot's built-in properties (like server.port) get autocomplete and inline documentation in application.properties automatically. spring-boot-configuration-processor extends that same experience to your own custom @ConfigurationProperties classes.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-configuration-processor</artifactId>
    <optional>true</optional>
</dependency>
@ConfigurationProperties(prefix = "shop")
public class ShopProperties {


    /**
     * Maximum number of items allowed in a single order.
     */
    private int maxItemsPerOrder = 20;


    /**
     * Whether guest checkout (without an account) is allowed.
     */
    private boolean guestCheckoutEnabled = true;


    // getters and setters
}
shop.max-items-per-order=50
shop.guest-checkout-enabled=false
Effect

Click Run to see what this code prints.

Common Mistakes

Avoid These Mistakes
  • Worrying that devtools or Lombok will bloat the production jar — both are marked optional and are excluded from the final artifact by the Spring Boot build plugins.
  • Forgetting to install the Lombok IDE plugin and being confused by editor errors that are not real compile errors.
  • Mixing Lombok's @Data on a JPA @Entity carelessly — its generated equals()/hashCode() can cause subtle bugs with lazy-loaded proxies and bidirectional relationships; many teams use @Getter/@Setter individually on entities instead of full @Data.
  • Not realizing spring-boot-configuration-processor only affects IDE tooling — omitting it does not break the actual property binding, just the autocomplete experience.

Frequently Asked Questions

No — it watches the compiled output directory (target/classes), so it restarts once your IDE or build tool actually recompiles the changed file, which is typically on save.

No, it is entirely optional. Plenty of production codebases skip it and write getters/setters by hand or use a code generator built into their IDE instead.

Yes, they are unrelated — the processor documents your @ConfigurationProperties fields regardless of whether those fields have hand-written or Lombok-generated accessors.

Summary

Devtools speeds up the restart loop, Lombok removes repetitive boilerplate, and the configuration processor brings your own custom properties into the same IDE experience as Spring's built-in ones — and none of the three affect what ships to production. Next, we look at rendering server-side HTML with a templating engine.

Next Lesson →

Templating Engine Dependencies