the build script

java {
    toolchain {

is not download jdk…

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':test'.
> Could not resolve all dependencies for configuration ':testRuntimeClasspath'.
   > Failed to calculate the value of task ':compileTestJava' property 'javaCompiler'.
      > No matching toolchains found for requested specification: {languageVersion=17, vendor=any, implementation=vendor-specific}.
         > No locally installed toolchains match (see and toolchain download repositories have not been configured (see

Auto download is enabled

edu>gradle -q javaToolchains

 + Options
     | Auto-detection:     Disabled
     | Auto-download:      Enabled

 + Eclipse Temurin JDK 11.0.19+7
     | Location:           C:\Users\nagku\.gradle\jdks\eclipse_adoptium-11-amd64-windows\jdk-11.0.19+7
     | Language Version:   11
     | Vendor:             Eclipse Temurin
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        Auto-provisioned by Gradle

Since Gradle 8, the auto-provisioning does not work out of the box anymore.
You have to declare where to download toolchains from, for example by applying the foojay plugin as documented at the link given in the error message.

1 Like

Oops… any reason for removing auto download feature… I was thinking it is a good lazy engineering feature… Documentation would need update on the point 4 as it still say it would auto download

Point 4 is perfectly valid.
It will auto-download.
Point 4 is saying “on the configured toolchain download repositories”.
In Gradle 7 there were some hard-coded.
In Gradle 8 you need to configure some, for example using the plugin as documented and also mentioned in my last comment.
Just if you don’t configure any, it does not know where to download from.

If yes, it would be nice to say how to configure too… i.e. which property and what are all the URLs that are valid at least on popular JDKs

Using foojay plugin a must for the download to work correctly as per my final experimentation that worked

If yes, it would be nice to say how to configure too

I did multiple times. :wink:

But good that you finally got it resolved as documented.

1 Like

It’s not very clear in the documentation what exactly one needs to setup to get auto downloads working *.

There’s an example of ‘made up’ in the docs.

So unless you already know how to set this up, it’s a great wall of text to those new to the whole great new ways of doing things.

I’ve been using gradle for years and used to spending time setting up stupidly complex config, but even I’m lost on this. Wasted hours on it already (upgrading to gradle 8 and all the new config). A line along the lines of:

TL;DR; “To setup the auto download for adoptium/whatever, use this config”.

Maybe this is buried in some sub page somewhere, so technically it’s there, but it’s hardly obvious to a newcomer. It’s helpful for there to be an on ramp for those not spending large chunks of their life in gradle config world

* Unless I really missed something obvious and am being a total blind

Not sure what your mean? It is directly documented what to use, and there is nothing “made up”. Do you maybe interpret “foojay” as “made up” just because it has “foo” in the name? It is not, as described above.

1 Like

yes name


is seen as madeup, may be a link that would help there.

Feel free to open a feature request and / or pull request. :wink:

Screenshot where it shows the ‘made up’ config

It would be helpful to show a valid config(s) for some of the popular jdk’s.

Gradle keeps complaining about not finding a valid jdk (even though they’re installed locally under /usr/local/java), nor does it download one.

Making it ‘just work’, would be nice

From Toolchains for JVM projects
[edit: add link to docs]

Did you also read the text around the example?
It clearly documents that one example earlier you have exactly the “just work” configuration you are after.
The example you quoted is for the more sophisticated case where you need a custom resolver for example because you have custom Java distributions or whatever.