gradle --no-daemon: run a build without the Gradle Daemon

By default Gradle runs builds in a long-lived background JVM, the Gradle Daemon, which keeps classes, caches and JIT-compiled code warm, so the second build is much faster than the first. ./gradlew build --no-daemon runs the build without reusing or leaving behind a daemon: the JVM exits when the build finishes. It is useful on throw-away CI machines, when debugging problems that only a fresh JVM shows, and in environments with little memory.

Commands

./gradlew build --no-daemon     # no daemon for this build
./gradlew --status              # list running daemons and their state
./gradlew --stop                # stop all daemons of this Gradle version

Set it permanently in gradle.properties (in the project or in ~/.gradle):

org.gradle.daemon=false

Daemon on or off

Single-use daemons

--no-daemon does not always mean "no extra JVM". When the build requires JVM arguments or a Java home that differ from the JVM running the Gradle client (set with org.gradle.jvmargs or org.gradle.java.home), Gradle starts a single-use daemon with the right settings and prints To honour the JVM settings for this build a single-use Daemon process will be forked. The process exits after the build, so the effect is the same; only the start-up is slower.

Pitfalls

• --no-daemon makes every build slow. On a developer machine prefer --stop once when a daemon misbehaves, then continue with the default.
• Daemons are tied to a Gradle version and a Java version. After upgrading the wrapper or switching JDKs, old daemons stay alive until they time out; --stop cleans them up.
• A build that fails only in a reused daemon (but passes with --no-daemon) usually points at a plugin that keeps static state; report it, and use --no-daemon as a workaround.
• JDK mismatches such as Unsupported class file major version are not fixed by the flag; they come from the Java version Gradle runs on.
• Diagnostics for failing builds come from --stacktrace, not from turning the daemon off.

FAQ