Build Cache and Performance

@Classpath marks a task input as a classpath: Gradle hashes the file contents in order but ignores file names and paths. @InputFiles treats each file's absolute path as significant, so it over-invalidates.

Inputs are the files/values a task reads; outputs are what it produces. For ad-hoc tasks you declare them at runtime via task.inputs.file()/dir()/property() and task.outputs.file()/dir() so Gradle can track changes.

UP-TO-DATE means Gradle skipped the task because its inputs and outputs haven't changed since the last run. Gradle compares snapshots of the declared inputs/outputs; if they match, it reuses the previous result.

@CompileClasspath fingerprints only the public API (ABI) of jars — class/method/field signatures — ignoring method bodies, private members and resources. So changing only an implementation detail upstream doesn't invalidate downstream compilation.

In settings.gradle(.kts) use normalization { runtimeClasspath { ignore 'build-info.properties' } }. It strips that file from the runtime-classpath fingerprint so a volatile, build-stamped entry doesn't cause needless cache misses or out-of-date tasks.

A cacheable task can store its outputs in the build cache and restore them later instead of re-running. It needs the @CacheableTask annotation and fully declared inputs and outputs.

Set org.gradle.caching=true in the project's gradle.properties so it is on for every build and every developer, or pass --build-cache on a single command to enable it just for that run.

FROM-CACHE means Gradle restored the task's outputs from the build cache instead of running it. UP-TO-DATE means outputs were already on disk and unchanged. Executed means the task actually ran.

By default the local build cache lives in ~/.gradle/caches/build-cache-1. It stores the outputs of cacheable tasks keyed by a hash, so a later build can reuse them instead of re-running the task.

In settings.gradle(.kts), inside the buildCache { remote<HttpBuildCache> { ... } } block. It takes effect very early — during settings evaluation, before any project is configured — because the cache must be ready before tasks run.

Pass --configuration-cache on the command line for a single run, or set org.gradle.configuration-cache=true in gradle.properties to enable it persistently for every build.

It is an HTML report Gradle generates listing every configuration-cache problem found, grouped by category, with the task or input that caused each one and a stack-trace-like location so you can find and fix the offending code.

Gradle serializes the resolved task graph — the tasks to run plus their configured state — to disk. On a cache hit it loads that snapshot and skips the whole configuration phase, going straight to executing tasks.

requested means the user asked for the configuration cache; active means it is actually operating. They diverge when, for example, the user sets it in gradle.properties but passes --no-configuration-cache on the command line — requested true, active false.

BuildFeatures is a Gradle service exposing whether opt-in features like the configuration cache are requested and active. A plugin gets it via gradle.serviceOf<BuildFeatures>() (or constructor injection) and reads configurationCache.requested / .active.

The daemon is a long-lived background JVM that runs your builds. Reusing a warm one skips JVM startup, class loading, and JIT warmup, so subsequent builds start much faster.

Gradle runs in a long-lived background JVM (the daemon). The first build pays JVM startup and HotSpot JIT warmup; later builds reuse that already-warm JVM, so they skip those costs and run faster.

It caps the maximum number of work items Gradle runs concurrently across the whole build — parallel tasks, test forks, Worker API jobs. It defaults to the number of CPU processors Gradle detects.

Pass --parallel on the command line, or set org.gradle.parallel=true in gradle.properties. Gradle then runs tasks from different projects concurrently using the daemon's worker threads, instead of one project at a time.

Gradle keeps an in-memory Virtual File System of file metadata and listens to OS file-change events. Between builds it retains that data so it doesn't re-read every file, making up-to-date checks faster.

A Build Scan is a shareable web report of a build's results. You publish one by adding --scan to any Gradle command; Gradle uploads the data and prints a scan URL.

Configuration builds the task graph by evaluating build scripts; execution runs the selected tasks' actions. A build can be slow because the graph takes long to build (configuration) or because the tasks themselves take long (execution).

--dry-run makes Gradle print the ordered list of tasks it WOULD run for your requested goal, without actually executing any of them. It's a safe way to preview the task graph.

Pass --profile to a build (e.g. ./gradlew build --profile). Gradle writes a self-contained HTML report to build/reports/profile/profile-<timestamp>.html showing where build time was spent.

Open the Build Scan's Timeline tab, sort tasks by duration (longest first), and read the top entry. It shows each task's wall-clock time so you can see which task dominated the build.