Gradle Incremental Builds and Build Cache

Direct Answer

Gradle can skip work in two related ways. Incremental tasks process only changed inputs when the task implementation supports incremental behavior. The build cache can reuse outputs of cacheable tasks when their declared inputs match a previous execution. Neither feature guarantees that only one changed Java file is compiled or that every task is restored after clean.

Code Example

// gradle.properties (enable local build cache)
org.gradle.caching=true

// settings.gradle (configure remote cache for team sharing)
buildCache {
    local {
        enabled = true
    }
    remote(HttpBuildCache) {
        url = 'https://cache.example.com/'
        push = true  // CI can push, developers pull
    }
}

// Example: first build (cache miss)
./gradlew clean build
// Output: 15 tasks executed, 0 from cache
// Build time: 45 seconds

// Example: second build with no changes (cache hit)
./gradlew clean build
// Output: 15 tasks executed, 15 from cache
// Build time: 5 seconds

// Incremental build (change one file)
// Edit src/main/java/com/example/OrderService.java
./gradlew build
// Output: 3 tasks executed (compileJava, classes, jar), 12 up-to-date
// Build time: 8 seconds

Common Mistakes & Pitfalls

• Confusing incremental compilation with the build cache: Freshers often think they're the same thing. Incremental compilation is Java-compiler-level (javac compiles only changed .java files); the build cache is Gradle-level (reuses entire task outputs like compiled classes, test results, or packaged JARs).
• Not enabling the cache: The build cache is opt-in via org.gradle.caching=true in gradle.properties. Many projects don't enable it and miss the benefits.
• Cache-unfriendly tasks: Custom Gradle tasks that don't declare inputs/outputs properly bypass the cache. If you write a task that reads files without telling Gradle, the cache won't work for that task.