skip to content

What are DevTools' LiveReload and development-time property defaults, and why do they exist?

level: middleimportance: should knowfreq 35%

answer

  1. LiveReload server port 35729 + browser extension
  2. one LiveReload server at a time
  3. dev defaults disable template/resource caching
  4. low-precedence PropertySource — your config still wins
  5. tightens edit→see loop

basics

~20 s

LiveReload is an embedded server (port 35729) that tells a browser extension to refresh the page when a resource changes. Property defaults are dev-friendly overrides DevTools applies automatically — mainly disabling template/resource caching — so your edits show up immediately.

solid answer

~40 s

DevTools includes two conveniences beyond restart. **LiveReload**: it starts an embedded LiveReload server (default port 35729); with the matching browser extension installed, the browser auto-refreshes whenever a monitored resource changes, so you don't hit F5. Disable it with `spring.devtools.livereload.enabled=false`; only one LiveReload server runs at a time. **Development-time property defaults**: many view/resource technologies cache for performance, which would hide your edits. DevTools adds a low-precedence property source that flips those to dev-friendly values — e.g. `spring.thymeleaf.cache=false`, `spring.freemarker.cache=false`, `spring.mustache.servlet.cache=false`, `spring.groovy.template.cache=false`, and disabling the static resource cache/chain. Because the property source is low precedence, anything you set explicitly still overrides it. Both features exist purely to tighten the edit-see-result loop and are gone in production since DevTools isn't packaged there.

code

properties · 5 lines
properties
# Turn LiveReload off if you don't use the browser extension
spring.devtools.livereload.enabled=false

# DevTools already sets these to false in dev; you could force caching on:
# spring.thymeleaf.cache=true   # overrides the DevTools dev default

go deeper

for a junior

Know LiveReload refreshes the browser and DevTools disables template caching.

for a middle

Explain the port, the extension requirement, and which caches get disabled.

for a senior

Explain the low-precedence property source and interaction with restart/excludes.

for a principal

Discuss version-dependent default sets and how to selectively re-enable caching per environment.

## LiveReload **LiveReload** is a small protocol/tool: a server watches for changes and pushes a refresh signal to a browser that has the **LiveReload extension** installed. DevTools ships an embedded LiveReload server that starts automatically. - **Default port**: 35729. - **Toggle**: `spring.devtools.livereload.enabled=false`. - **Only one at a time**: if you run several DevTools apps, only the first LiveReload server binds the port; the others quietly skip it. If you want a specific one to own it, disable LiveReload on the others. - It reacts to resource changes (including the excluded-from-restart static assets), so editing `static/`/`templates/` refreshes the browser **without** a full context restart. ## Development-time property defaults For speed, production configurations of templating and web-resource layers **cache** compiled templates and resource metadata. During development that caching means you edit a template and see... the old one. DevTools solves this by contributing a **`PropertySource`** of dev defaults, applied with **low precedence** so your explicit config always wins. Representative overrides DevTools applies: - `spring.thymeleaf.cache=false` - `spring.freemarker.cache=false` - `spring.groovy.template.cache=false` - `spring.mustache.servlet.cache=false` - `spring.web.resources.cache.period=0` / disable the resource chain cache - more verbose condition/logging defaults to aid debugging The exact list can vary by Boot version, but the principle is constant: **turn off caching and make behavior transparent** during development. ### Why low precedence matters Because these are applied *below* your `application.properties`/`application.yml` and command-line args, you keep full control. If you deliberately want caching on even in dev, setting `spring.thymeleaf.cache=true` yourself overrides the DevTools default. ## Relationship to the rest of DevTools - **Restart** handles server-side *code* changes (rebuild the context). - **LiveReload** handles *browser* refresh on resource changes. - **Property defaults** ensure the changes you make are actually *visible* (not masked by caches). Together they form the fast feedback loop. All three vanish in production because DevTools isn't on the production classpath. ## Gotchas - LiveReload needs the **browser extension**; without it the server runs but nothing refreshes. - If a template change doesn't appear, it's often because caching wasn't disabled (e.g. DevTools not on the classpath, or you overrode the cache property to true). - Static assets are excluded from restart by default, so they rely on LiveReload for the browser to pick them up.

  • You edited a Thymeleaf template but the browser shows the old content. What's likely wrong?
    Template caching is on. Normally DevTools sets spring.thymeleaf.cache=false, so either DevTools isn't on the classpath, or you explicitly set the cache property to true, or the browser just needs a refresh (LiveReload/extension not active).

saying these in an interview costs you the question

  • Thinking the DevTools property defaults are high precedence and override your explicit config.
  • Believing LiveReload works without the browser extension.
  • Assuming these caching-off defaults apply in production too.

context

resolving links…