skip to content

Show the minimal settings.gradle.kts setup that lets Gradle download a missing JDK, and explain what each piece does.

level: juniorimportance: must knowfreq 40%

answer

  1. apply foojay-resolver-convention in settings
  2. convention auto-registers foojay repo
  3. request toolchain in build.gradle.kts
  4. languageVersion = JavaLanguageVersion.of(17)
  5. download into shared toolchains cache

basics

~10 s

Apply the foojay-resolver-convention plugin in settings.gradle.kts. It registers the Foojay repository under toolchainManagement, so Gradle can auto-download a missing toolchain JDK.

solid answer

~40 s

The one-liner is applying the convention plugin in `settings.gradle.kts`: ```kotlin plugins { id("org.gradle.toolchains.foojay-resolver-convention") version "0.8.0" } ``` That plugin does two things: it puts the `FoojayToolchainResolver` on the classpath, and it auto-registers a `foojay` repository inside `toolchainManagement { jvm { javaRepositories { } } }`. With that in place, when a build requests a toolchain (e.g. Java 17) that isn't installed locally, Gradle queries Foojay's Disco service for a matching JDK and downloads it into its shared toolchains cache. No manual `toolchainManagement` block is needed — the convention plugin writes the registration for you. The toolchain itself is still *requested* in build.gradle.kts via `java { toolchain { languageVersion = JavaLanguageVersion.of(17) } }`.

code

kotlin · 11 lines
kotlin
// settings.gradle.kts
plugins {
    id("org.gradle.toolchains.foojay-resolver-convention") version "0.8.0"
}

// build.gradle.kts (the request side)
java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

go deeper

for a junior

Recall the single plugin line in settings.gradle.kts and that the toolchain is requested separately in build.gradle.kts.

for a middle

Explain that the convention plugin auto-registers the foojay repository and trace the request-to-download flow.

for a senior

Note version pinning for reproducibility and where this sits relative to local detection and auto-download.

for a principal

Standardize the settings setup across repos (e.g. via a shared convention plugin) and decide org-wide whether public Foojay is acceptable.

## The minimal happy path For most projects, enabling auto-provisioning is a single plugin application in `settings.gradle.kts`: ```kotlin // settings.gradle.kts plugins { id("org.gradle.toolchains.foojay-resolver-convention") version "0.8.0" } rootProject.name = "my-app" ``` ### What it does - **Provides a resolver**: the `FoojayToolchainResolver` class, which knows how to ask the Foojay Disco API for a JDK matching a spec. - **Registers it**: the *convention* variant auto-writes the equivalent of: ```kotlin toolchainManagement { jvm { javaRepositories { repository("foojay") { resolverClass = org.gradle.toolchains.foojay.FoojayToolchainResolver::class.java } } } } ``` …so you don't have to. ## Where the toolchain is requested The *registration* (settings) is separate from the *request* (build script). In a project's `build.gradle.kts`: ```kotlin java { toolchain { languageVersion = JavaLanguageVersion.of(17) } } ``` This declares "compile/test/run with Java 17." If no Java 17 JDK is detected locally, Gradle uses the registered Foojay resolver to download one. ## End-to-end flow 1. Build requests Java 17 toolchain. 2. Gradle checks locally detected JDKs — none match. 3. Auto-download is enabled (default), and a repository is registered → Gradle calls the Foojay resolver. 4. Resolver returns a download URI for a Java 17 JDK matching this OS/arch. 5. Gradle downloads, extracts, and caches it; the build proceeds. ## Pinning the version Use a specific plugin version (e.g. `0.8.0`) rather than letting it float, so toolchain provisioning behavior is reproducible across machines and CI.

  • Which file holds the plugin application and which holds the toolchain request?
    The foojay-resolver-convention plugin goes in settings.gradle.kts (registration is build-wide). The toolchain { languageVersion = ... } request goes in a project's build.gradle.kts.
  • Why pin the foojay plugin to a specific version?
    To keep provisioning behavior reproducible across developers and CI. A floating version could change resolution behavior or the resolver API unexpectedly.

saying these in an interview costs you the question

  • Putting the toolchainManagement registration in build.gradle.kts.
  • Thinking applying the plugin alone selects the Java version — you still request the toolchain in the build script.

context

resolving links…