For CI and release builds, no: install approved JDKs yourself and turn auto-download off, so you know exactly which compiler and runtime built your software. For developer laptops it is a convenience that needs a deliberate resolver choice. Gradle only downloads when a toolchain repository is configured, and its docs describe no integrity check of the download.
How auto-provisioning works
Per Gradle's toolchain documentation, if no matching local JDK exists, Gradle can download one, but only when a toolchain download repository is configured. Repository definitions come from settings plugins. The example in the docs is the Foojay Toolchains Plugin, which uses the foojay Disco API. Gradle installs downloaded JDKs in the Gradle user home, and only downloads GA releases.
Two details matter for planning. Provisioned JDKs are never revisited and automatically updated by auto-provisioning, so they can age. And Gradle downloads from the first repository in the list that provides a match.
Why it is a supply chain choice
The JDK compiles your code and runs your tests. It is as central as any dependency. A settings plugin that decides where JDKs come from is itself a dependency of the build, which is why it belongs in your plugin review.
The page we read does not describe checksum or signature verification for downloaded JDKs, so do not assume one. It does say installations that are missing a bin/java executable are ignored with a warning.
Choosing a policy
| Environment | Suggested policy | Why |
|---|---|---|
| Release CI | Auto-download off, JDK baked into a reviewed image | Known compiler source |
| General CI | Off, or on with an internal resolver | Repeatability |
| Developer machine | On, with a resolver you chose | Convenience |
| Air gapped | Off | No network |
Steps
- Decide which JDK vendor and version your release builds use, and record it.
- Install it in the CI image from a source you verify.
- Set the org.gradle.java.installations.auto-download property to false, in gradle.properties or with a system property. The docs say to make sure the JDK is installed first, then stop the daemon.
- If you allow auto-download, review the resolver plugin and its version like any other plugin.
- Record the JDK in your build metadata or SBOM so you can answer which JDK built a release.
- Revisit provisioned JDKs on a schedule, since Gradle will not update them.
What to record for later questions
Customers and auditors increasingly ask what built the product. Capture the JDK vendor, version and source, plus the Gradle version and plugin versions, alongside the artifact. See signature, provenance and SBOM attestation for how those records relate.
Try it yourself
Click through it at your own pace, or open it full screen.
See how one control maps to several frameworks. Build environment records are a common evidence request.
Safeguard's compliance and evidence automation helps collect records like these, and the free scan at gold.safeguard.sh/scan covers dependencies.
Quick check
Does Gradle download a JDK by default?
Only if a toolchain download repository is configured through a settings plugin, according to the Gradle docs.
Are downloaded JDKs updated automatically?
No. The docs say auto-provisioned JDKs are never revisited and updated by auto-provisioning.
Sources
Last reviewed: 19 October 2026.
