The toolchain languageVersion is a lazy Property. Why does Gradle model it lazily rather than resolving the JDK at configuration time?

## Lazy configuration in one paragraph Gradle separates **configuration** (building the task graph) from **execution** (running tasks). The `Provider`/`Property` API lets a value be *declared* during configuration but *computed* later. A `Property<T>` is a settable, lazy container; a `Provider<T>` is a read-only lazy value. The toolchain's `languageVersion` is a `Property<JavaLanguageVersion>`, so the version you assign is just a recorded intent. ## Why not resolve the JDK eagerly? Resolving a toolchain means: scan known JDK locations, match the requested version (and vendor), and — if missing and provisioning is enabled — potentially **download a JDK over the network**. Doing that at configuration time would: - Slow down *every* invocation, including `./gradlew help` or `./gradlew tasks` that compile nothing. - Couple the task graph to environment/network state, hurting reproducibility. - Break the **configuration cache**, which serialises the configured model and must avoid environment access at configuration time. By keeping it lazy, Gradle resolves the JDK only when a task that genuinely needs it executes — and the result feeds into incremental build / up-to-date checks correctly. ## How tasks consume the toolchain The Java plugins wire the toolchain into tasks via the `JavaToolchainService`: ```kotlin val service = extensions.getByType<JavaToolchainService>() tasks.withType<JavaCompile>().configureEach { javaCompiler = service.compilerFor { languageVersion = JavaLanguageVersion.of(21) } } ``` `compilerFor { }` returns a `Provider<JavaCompiler>`; `launcherFor { }` returns a `Provider<JavaLauncher>` for `Test`/`JavaExec`. These are lazy providers — the actual `JavaCompiler`/`JavaLauncher` (which knows the JDK home) materialises at execution. ## Wiring from external inputs Because it's a `Property`, you can source the version dynamically without breaking laziness: ```kotlin java { toolchain { languageVersion = providers.gradleProperty("buildJdk") .map { JavaLanguageVersion.of(it.toInt()) } .orElse(JavaLanguageVersion.of(21)) } } ``` The `map`/`orElse` chain is itself lazy — nothing is read until resolution. This is how teams parameterise the toolchain per environment without `if`-statements at configuration time. ## Configuration-cache angle The configuration cache stores the configured task graph and replays it, skipping configuration on cache hits. For that to work, configuration must not read live environment/JDK state. A lazily-modelled toolchain stores only the *request*; resolution (an execution-time concern) happens after a cache hit just as it would on a miss — so toolchains are configuration-cache compatible by design. ## Interview signal Mentioning that `languageVersion` is a `Property`, that resolution is deferred to execution, and that this is what keeps it configuration-cache friendly and composable, distinguishes a senior who understands Gradle's lazy model from someone who only knows the DSL surface.