skip to content

What is mvnd (the Maven Daemon) and why can it be faster than plain mvn?

level: seniorimportance: should knowfreq 35%

answer

  1. resident daemon JVM
  2. skips JVM startup + JIT warmup
  3. parallel by default
  4. native client (GraalVM)
  5. best for iterative dev, --stop to reset

basics

~10 s

mvnd runs Maven inside a long-lived background daemon (JVM) that stays warm between builds. It avoids repeated JVM startup and lets the JIT-compiled, class-loaded state be reused, so repeated builds start faster.

solid answer

~50 s

`mvnd` is a separate distribution that embeds Maven in a resident daemon process. Each `mvn` invocation normally pays a cold cost: spin up a fresh JVM, load and verify classes, and let the JIT warm up — only to throw it all away when the build ends. mvnd keeps one or more daemon JVMs alive, so the second and later builds skip JVM startup and reuse JIT-optimized code and loaded plugin classes. It also defaults to parallel building (like `-T`) and uses a native client (built with GraalVM) for instant CLI response. Trade-offs: the daemon holds memory between builds, state can become stale (you can `mvnd --stop`), and it shines most for repeated incremental builds in dev — a single clean CI build sees less benefit. It is largely a drop-in replacement and reads the same POMs/settings.

code

bash · 3 lines
bash
mvnd clean install   # starts/uses a warm daemon
mvnd --status        # show daemons
mvnd --stop          # reset stale daemon state

go deeper

for a junior

Knows mvnd keeps a warm process so builds start faster.

for a middle

Can explain JVM startup + JIT warmup reuse and that it's a near drop-in replacement.

for a senior

Weighs dev-loop vs CI benefit, memory cost, stale-daemon resets, and combining with caching.

for a principal

Decides org tooling strategy — mvnd for local dev, cache + -T for CI — and manages rollout/standardization.

## The problem mvnd solves A plain `mvn` command starts a brand-new Java Virtual Machine every time. That JVM must: load hundreds of Maven/plugin classes, verify bytecode, and run interpreted until the Just-In-Time (JIT) compiler decides which methods are 'hot' enough to compile to native code. By the time the JVM is warm, the build is over and everything is discarded. For short, frequent builds this startup tax dominates. ## What mvnd is `mvnd` (the Maven Daemon, an Apache Maven project) ships a thin **native client** plus a **background daemon**. The first build launches a daemon JVM that stays resident. Subsequent builds connect to that warm daemon, so they: - skip JVM startup and class loading, - reuse JIT-compiled hot code, - keep plugin classloaders and some caches alive. It also enables **parallel builds by default** (equivalent to `-T`) and can spawn multiple daemons. ## When it helps (and when it doesn't) - **Big win:** iterative local development — repeatedly running `mvnd install`/`test` on the same project. - **Smaller win:** one-shot CI builds on a fresh runner — there is no prior warm daemon, so you mostly pay first-build cost (though parallelism still helps). ## Operational notes - It is a near drop-in: same POMs, same `settings.xml`, same lifecycle/goals. Alias `mvn=mvnd` often 'just works'. - The daemon consumes memory between builds. - Stale state? `mvnd --stop` kills daemons; `mvnd --status` lists them. ```bash mvnd clean install # first run starts the daemon mvnd test # reuses the warm daemon — faster startup mvnd --status # list running daemons mvnd --stop # shut them down ``` ## Relation to other tooling mvnd is about *process/JVM reuse*; the build-cache extension is about *skipping work whose inputs are unchanged*. They are complementary and can be combined.

  • Why does mvnd help dev loops more than a single CI build?
    CI runners are usually fresh per job, so there's no pre-warmed daemon to reuse — you pay cold startup once. Dev reuses the same warm daemon across many builds, amortizing startup and JIT cost.
  • How is mvnd different from the build-cache extension?
    mvnd reuses the JVM process (faster startup/JIT); the cache extension skips executing goals when their inputs are unchanged (avoids redoing work). They address different costs and can be combined.

Plain mvn is starting a car's engine, driving one block, and turning it off every trip. mvnd leaves the engine idling so the next trip starts instantly — at the cost of burning some fuel while parked.

saying these in an interview costs you the question

  • Saying mvnd is a different build tool with a new POM format (it reads standard Maven POMs)
  • Claiming mvnd caches build outputs the way the cache extension does (it reuses the JVM, not goal results)
  • Assuming it always speeds up clean CI builds by a lot

context

resolving links…