[Windows build from source] Gradle JDK auto-download doesn't work as expected

[piomar123]

According to https://docs.openrewrite.org/reference/building-openrewrite-from-source Gradle should first auto-detect and if not found then download the missing JDKs:

If you are able to access Adoptium, then Gradle will automatically download and install any needed JDKs which you may be missing.

But if I understand correctly, from Gradle version 8, the functionality to auto-download requires an additional configuration in the project settings: https://docs.gradle.org/8.6/userguide/toolchains.html#sec:provisioning
I couldn't find any related Toolchain download repositories in the project settings, so I assume this functionality won't work for OpenRewrite. Hence, either the documentation should be corrected or such configuration should be added to the project to allow auto-download.

What version of OpenRewrite are you using?

I am using main branch - commit dd77eddabc9dbb0003f3b4be08673960ac19402b

• Gradle wrapper v8.6

How are you running OpenRewrite?

I am trying to build OpenRewrite from sources according to https://docs.openrewrite.org/reference/building-openrewrite-from-source

My environment:
Windows 10 Enterprise
Version 22H2
Installed on ‎06.‎10.‎2021
OS build 19045.3930
Experience Windows Feature Experience Pack 1000.19053.1000.0

Java "installations" (unpacked zips):

• C:\jdk8u402-b06
• C:\jdk-11.0.12+7
• C:\jdk-17.0.8.1+1

Environment variables include:

JAVA_HOME=C:\jdk-17.0.8.1+1\
PATH=...;C:\jdk-17.0.8.1+1\bin\;C:\apache-maven-3.9.5\bin\;...

What is the smallest, simplest way to reproduce the problem?

Match the environment and run:

./gradlew build

What did you expect to see?

A successful build.

What did you see instead?

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':rewrite-gradle'.
> Failed to query the value of task ':rewrite-gradle:compileGroovy' property 'javaLauncher'.
   > Cannot find a Java installation on your machine matching this tasks requirements: {languageVersion=8, vendor=any, implementation=vendor-specific} for WINDOWS on x86_64.
      > No locally installed toolchains match and toolchain download repositories have not been configured.

* Try:
> Learn more about toolchain auto-detection at https://docs.gradle.org/8.6/userguide/toolchains.html#sec:auto_detection.
> Learn more about toolchain repositories at https://docs.gradle.org/8.6/userguide/toolchains.html#sub:download_repositories.
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.

Are you interested in contributing a fix to OpenRewrite?

Yes, but I need to discuss the best solution for this issue.

Workaround

When using simple unzipped JDKs directly under C:\ directory it looks like the Gradle also fails to auto-detect the installations.
As a workaround I used Maven Toolchains configurations under ~/.m2/toolchains.xml pointing to the unzipped JDKs:

<?xml version="1.0" encoding="UTF-8"?>
<toolchains>
  <!-- JDK toolchains -->
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>1.8</version>
    </provides>
    <configuration>
      <jdkHome>C:\jdk8u402-b06</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>11</version>
    </provides>
    <configuration>
      <jdkHome>C:\jdk-11.0.12+7</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>17</version>
    </provides>
    <configuration>
      <jdkHome>C:\jdk-17.0.8.1+1</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>21</version>
    </provides>
    <configuration>
      <jdkHome>C:\jdk-21.0.2+13</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

Maybe there is a better way to force Gradle to find the installations?

[timtebeek]

Thanks for pointing this out and linking to the relevant sources @piomar123 ! I'm guessing this was missed when we upgraded Gradle.

We had a similar PR opened against rewrite-gradle-plugin recently; you might be interested to weigh in there with the best way forward:

• Add auto JDK download rewrite-gradle-plugin#272

[shanman190]

So there are two parts here.

• Tim's linked to the other issue that is found where a user is asking about auto download within the Gradle plugin, but it likely could be available for all rewrite projects.

• Gradle proper performs auto detection via a specific method. OpenRewrite itself other than adding the auto downloader, doesn't have any control over influencing that. To see how Gradle performs auto detection or how to enrich the auto detection with user configurable options you should checkout https://docs.gradle.org/current/userguide/toolchains.html#sec:auto_detection and https://docs.gradle.org/current/userguide/toolchains.html#sec:custom_loc for details on how to set this up. Also specifically, configuring Maven toolchains as you've described as no impact on the Gradle ecosystem as you'll see in the aforementioned Gradle documentation.

[shanman190]

@timtebeek, from an opinion question standpoint would you rather see:

• OpenRewrite projects updated to re-enable auto download of toolchains (missed migration when moving to Gradle 8.0+).
• Update the docs to remove any references to auto downloading of Java toolchains and explicitly state that the user needs to install the required Java versions.

[timtebeek]

Thanks for the reminder @shanman190 ! I'm leaning towards updating the docs, as I'd find it unlikely that folks don't have a matching Java version available already, or if they don't, they might have another preferred mechanism of obtaining such a JDK (SDKman, Jenv, homebrew, Chocolatey, ...)

I can be swayed if there's a convincing argument for auto download, but when I'm giving a workshop I wouldn't want folks to unknowingly all start to download JDKs when it's likely that they have one already in a custom path. Would you agree there?

If so we'd want to remove the line highlighted at the very top here from the docs @mike-solomon 🙏🏻

[shanman190]

Yeah, I can agree in part that if the user is using custom locations that are unknown to Gradle's discovery mechanism -- especially in restrictive environments or environments where bandwidth is limited -- it can certainly be surprising. This is actually exactly the reason that Gradle dropped the auto download from being internally done and giving control to users via an API as part of the Gradle 8.0 release.

Gradle's lookup mechanisms include system installs, SDKman, jenv, and a few others. Things like chocolatey and homebrew generally install into the system install locations, so those should be auto discovered without any problem.

To me on a personal level, is a coin flip as to what to do.

[timtebeek]

Also on the fence a bit 😅 good to hear common paths are at least handled; that should surprise fewer folks. Beyond that it's then perhaps most welcoming and lowering the bar to entry if we do automatically download or at least configure as needed for projects, especially seeing how today we use Java 17 for tests, but that might change to Java 21 at some point.

Just not sure what changes we should make, so any help appreciated! :)

[shanman190]

So funny enough, it's actually already Java 21 due to the rewrite-java-21 module. It's just for core devs, we mostly make use of IDE.properties and don't mess with the Java 21 module very often. You are right though that test compatibility is still set to Java 17.