skip to content

JVM Toolchains

Declaring the JDK a build compiles and tests with, independent of the JVM running Gradle: vendor selection, detection, auto-provisioning, and per-task overrides. Interviewers ask because toolchains end the whole JAVA_HOME-mismatch class of problems.

on this pageshow

explore

questions

page 2 of 2

A developer sets `vendor = JvmVendorSpec.AZUL` but only Temurin is installed and provisioning is disabled. What happens, and how would you diagnose it?

level: seniorimportance: should knowfreq 26%

basics

~10 s

Toolchain resolution finds no Azul JDK; with provisioning off it can't download one, so the build fails with a 'No matching toolchain' error. Diagnose with ./gradlew javaToolchains to list detected JDKs and their vendors.

open as a page

How do you point the Javadoc task at a specific JDK's javadoc tool, and what fields can you set in the toolchain spec passed to javadocToolFor/launcherFor besides languageVersion?

level: middleimportance: nice to knowfreq 22%

basics

~10 s

Set the Javadoc task's javadocTool to javaToolchains.javadocToolFor { languageVersion = ... }. In the spec you can also set vendor (e.g. JvmVendorSpec.ADOPTIUM) and nativeImageCapable/implementation to constrain which JDK matches.

open as a page

How would you constrain a toolchain to GraalVM, and what is special about resolving the GraalVM vendor compared to a plain HotSpot distribution?

level: seniorimportance: nice to knowfreq 14%

basics

~20 s

Set vendor = JvmVendorSpec.GRAAL_VM. It selects a GraalVM-based JDK (which bundles the Graal compiler / native-image tooling). Resolution is the same detect-then-provision flow, but you usually pair it with native-image plugins and may need a specific provisioning source.

open as a page

How would you design a team/CI policy for JDK detection so builds are reproducible across dev laptops and pipelines?

level: principalimportance: nice to knowfreq 20%

basics

~20 s

Leave detection on for developer convenience but standardize where JDKs live. On CI, disable auto-detection and pin JDKs through a fixed set of fromEnv variables the CI image always exports, so every pipeline resolves the same installations.

open as a page

How would you govern toolchain auto-provisioning across an organization for security and reproducibility?

level: principalimportance: nice to knowfreq 18%

basics

~20 s

Pre-provision JDKs in build images so foojay isn't hit at build time, disable auto-download in CI, optionally point a resolver at an internal mirror instead of foojay, and pin/verify the JDKs so builds stay reproducible and auditable.

open as a page

showing 31–35 of 35