Support Scoop installed JDK discovery on Windows

[GingerGeek]

Expected Behavior

Gradle should detect JDKs installed by Scoop (GitHub).

Scoop is a popular (20k+ stars) installer on Windows for command-line, non MSI installers similar to SDKMAN!, asdf and jabba that are already installed.

Through the Java bucket scoop can manage the install of many different JVM versions and distributions

Current Behavior (optional)

Currently Gradle does not detect the installation location of JDKs installed with scoop, unless invoked or if JAVA_HOME points to one of the installs. Builds may fail if they can't detect correctly installed required JVM versions.

Context

Scoop installs apps in self-contained folders, generally under %USERPROFILE%/scoop/apps

Each combination of JVM version (8, 11, 17, etc) and distribution (Temurin, Corretto) has it's own folder e.g temurin21-jdk.

With each folder there is a symlink of current that links to the latest installed version of that JVM within the folder.

Also see ScoopInstaller/Java#504

[ljacomet]

This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.

---

• Should we add this support?
• Or should Gradle instead offer an SPI allowing users to add their own detection providers? (this is not a request for the attached PR to be modified to do that)

Related:

• Add more Java installations detection options #16645

[GingerGeek]

Thanks,

I agree you could quite easily bloat Gradle with detection for every toolchain out there, especially as in order to "fully" support them it becomes quite complex. e.g. with scoop installation directories can be varied and to "fully" resolve the installation locations you would have to read system environment and config files with the same logic as scoop itself.

The other toolchains seem to be done on a "as-default" basis so they just check the default paths... which is the current implementation in the PR

The SPI may be a preferred method but the DX would be a challenge I feel. You wouldn't want to include logic like this in project files with this, but similarly the experience of modifying gradle user settings is not always friendly.