Changes to toolChain implementation are ignored

[bigdaz]

When the java.toolchain specification is changed by adding/removing/changing the implementation, this change is ignored and the previously configured toolchain will be used.

This problem is presumably because the download file name does not encode this information.

Note that a similar issue occurs with Gradle 7.4 nightly, when changing the vendor from ADOPTIUM to IBM_SEMERU.

Expected Behavior

The specified toolchain should be downloaded, provisioned and used.

Current Behavior

The change to toolchain spec is ignored.

Steps to Reproduce

1. Checkout the main branch of https://github.com/bigdaz/gradle-toolchain-issues
2. Run ./gradlew -g HOME build : the build should fail as described in Error extracting downloaded toolchain for JvmImplementation.J9 #19382
3. Change the build.gradle file to comment out the implementation set on the Java toolchain spec.
4. Run ./gradlew -g HOME build again : the same error will occur.
5. rm -rf HOME to start with a clean Gradle User Home
6. Run ./gradlew -g HOME build again : this time the toolchain is successfully extracted.

[jbartok]

This happens as it does because the implementation name is not included in the filename of the JDK/JRE archive downloaded by our auto-provisioning mechanism. For J9 you get a corrupted archive, which is downloaded successfully but fails to be unarchived. When you remove the J9 implementation criteria from the toolchain spec you would expect a fresh archive to be downloaded, but it doesn't. The old, corrupted one is there and is still matched as what you want.

[bigdaz]

@jbartok I think there's a further issue with differentiating toolchains: when we extract the JDK into the ~/.gradle/jdks directory, we use the root directory from the archive as the target directory name. I haven't confirmed, but I'm pretty sure that this can also result in us using the incorrect JDK.

To clarify, I downloaded 2 different JDK 17 implementations (openJ9 and hotspot) and they both have a root directory named jdk-17.0.1+12. This means that even if we give the downloaded archives different names, the first one extracted will always win. You should be able to confirm this by changing the implementation type and looking for this log message

[jbartok]

Ok, thank you, unfortunately, that's most likely true... Will investigate, maybe pull it out into a separate PR.

[ljacomet]

Closed by #19439