What is Spring Boot DevTools and what does it give you during development?
answer
- optional/developmentOnly dependency
- restart + LiveReload + property defaults + prod-exclusion
- not hot-swap, not JRebel
- self-disables from packaged jar
- dev experience only
basics
~20 sspring-boot-devtools is an optional dev-only dependency. It automatically restarts your app when class files change, refreshes the browser via LiveReload, applies developer-friendly property defaults (like disabling template caching), and is left out of production jars.
solid answer
~40 sSpring Boot DevTools is an optional module you add with the `spring-boot-devtools` dependency to speed up the dev loop. Its four headline features: (1) automatic restart — when files on the classpath change (e.g. after your IDE recompiles), it restarts the application context quickly using a special classloader; (2) LiveReload — an embedded server that tells a browser extension to refresh when resources change; (3) dev-time property defaults — it disables caching for Thymeleaf/FreeMarker/etc. and tweaks other properties so you see changes immediately; (4) automatic disablement in production — it's marked `optional`/`developmentOnly` so it doesn't leak into a deployed jar, and it self-disables when the app runs from a fully packaged jar. It's a developer-experience tool, never a production feature.
code
kotlin · 11 lines// build.gradle.kts — dev-only, kept out of the production jar
dependencies {
developmentOnly("org.springframework.boot:spring-boot-devtools")
}
// Maven equivalent:
// <dependency>
// <groupId>org.springframework.boot</groupId>
// <artifactId>spring-boot-devtools</artifactId>
// <optional>true</optional>
// </dependency>go deeper
Know the four features and that it's dev-only.
Explain restart vs LiveReload and the developmentOnly scope.
Understand the two-classloader restart and property-default mechanism.
Discuss production-exclusion guarantees, remote DevTools risk, and classloader edge cases.
## What it is **Spring Boot DevTools** is an optional module distributed as the artifact `org.springframework.boot:spring-boot-devtools`. You add it only for development; it is designed to make no difference (and cause no risk) in production. It bundles several loosely related developer-experience features. ### 1. Automatic restart When any file on the classpath changes, DevTools restarts the running application. The key point: this is **not** a JVM restart and **not** hot-swapping bytecode into a running class. It uses **two classloaders**: - a **base classloader** that loads jars that don't change (third-party libraries), and - a **restart classloader** that loads *your* code (the directories on the classpath, i.e. your compiled classes and resources). On a change, DevTools throws away the restart classloader and creates a new one, reloading only your classes. Because the large, unchanging library classes stay loaded in the base classloader, this restart is far faster than a cold JVM start. The restart is triggered by your build/IDE writing new `.class` files — DevTools watches the classpath. In IntelliJ you typically trigger it with Build Project (or enable build-on-save); in Eclipse a save recompiles automatically. ### 2. LiveReload DevTools starts an embedded **LiveReload server** (default port **35729**). With the LiveReload browser extension installed, the browser is told to refresh automatically whenever a resource changes. You can turn it off with `spring.devtools.livereload.enabled=false`. Only one LiveReload server runs at a time across your apps. ### 3. Property defaults (dev-time) Several Spring technologies cache aggressively for performance, which hides your edits during development. DevTools overrides those defaults so you see changes immediately — for example it sets `spring.thymeleaf.cache=false`, `spring.freemarker.cache=false`, `spring.mustache.servlet.cache=false`, `spring.groovy.template.cache=false`, disables the web resource chain cache, and enables more detailed logging conditions. These are applied as a `PropertySource` with low precedence, so anything you set explicitly still wins. ### 4. Exclusion from production DevTools is meant to be development-only in two independent ways: - **Not shipped**: you declare it as `developmentOnly` (Gradle) or `optional` (Maven) so it is not packaged transitively into the production artifact. - **Self-disabling**: even if the jar were present, DevTools disables itself when it detects the app was started from a **fully packaged jar/war** (i.e. not exploded classes). It also disables when it detects a `java -jar` run of a repackaged archive. You can force-disable with `spring.devtools.restart.enabled=false` (as a System property to also stop the watcher thread) or the env var behavior. ### Configuration highlights - `spring.devtools.restart.enabled` — turn restart on/off. - `spring.devtools.restart.exclude` / `additional-exclude` — paths that change but should **not** trigger a restart (e.g. static assets, which only need a reload, not a restart). Defaults exclude `META-INF/maven`, `META-INF/resources`, `resources`, `static`, `public`, `templates`. - `spring.devtools.restart.trigger-file` — only restart when a specific file changes, giving you manual control over when the restart fires. - `spring.devtools.restart.poll-interval` / `quiet-period` — how the file watcher batches changes. - **Global settings**: `~/.config/spring-boot/spring-boot-devtools.properties` applies to all your projects. ### Remote DevTools There is a **remote** mode (`spring.devtools.remote.secret`) that can push restarts to a remotely running app. It is a security risk (it can execute code on the server) and must never be enabled against production. ### Gotchas - Restart uses two classloaders, so objects created before the restart become incompatible with the new classloader — this is why you occasionally see `ClassCastException`/deserialization issues across restarts, and why caches/serialized sessions may need care. - Static/frontend assets are in the **exclude** list by default: editing them triggers a **LiveReload** (browser refresh) but not a full restart. - DevTools is **not** JRebel: it reloads state by rebuilding the context, so any in-memory state is lost on each restart. - Registering a custom object with the base classloader vs restart classloader matters for third-party libs that cache class references.
- Does DevTools make it safe to run in production?No. It is development-only. It's declared developmentOnly/optional so it isn't packaged, and it self-disables when launched from a fully packaged jar. Its features (auto-restart, disabled caching) would harm production.
- What is the difference between DevTools restart and LiveReload?Restart rebuilds the Spring application context (server-side) when your compiled classes change. LiveReload just tells the browser to refresh when a resource changes; it's client-side and needs the browser extension.
saying these in an interview costs you the question
- Thinking DevTools hot-swaps bytecode like JRebel with no context restart.
- Believing DevTools should or can be safely used in production.
- Claiming you must manually remove DevTools before deploying (the build scope already excludes it).