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 pageshowhide
explore
- Declaring a Toolchain5 questions
- Vendor & Implementation Selection5 questions
- Local JDK Detection5 questions
- Auto-Provisioning & Foojay Resolver5 questions
- toolchainManagement Repositories5 questions
- Per-Task Toolchains5 questions
- Toolchains in Android Builds5 questions
questions
page 2 of 2A developer sets `vendor = JvmVendorSpec.AZUL` but only Temurin is installed and provisioning is disabled. What happens, and how would you diagnose it?
basics
~10 sToolchain 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.
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?
basics
~10 sSet 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.
How would you constrain a toolchain to GraalVM, and what is special about resolving the GraalVM vendor compared to a plain HotSpot distribution?
basics
~20 sSet 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.
How would you design a team/CI policy for JDK detection so builds are reproducible across dev laptops and pipelines?
basics
~20 sLeave 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.
How would you govern toolchain auto-provisioning across an organization for security and reproducibility?
basics
~20 sPre-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.
showing 31–35 of 35