Context

The current Java toolchain mechanisms only allow downloading (provisioning) JDKs from AdoptOpenJDK. However, there are multiple JDKs which are available via different means, and could be automatically provisioned by Gradle too.

For this purpose, as discussed in Slack this pull request adds support for custom toolchain provisioning.

In a nutshell, a provisioning service is responsible for:

• providing a list of candidates for provisioning, given a toolchain spec
• providing a provisioner given a specific selected candidate

A plugin can then register such a provisioning service on the toolchains service. This would typically allow the GraalVM team to provide such a mechanism in the GraalVM native image plugin.

IMPORTANT: For legal reasons, this pull request must not be merged until approved by @graemerocher

Some things that I noticed while working on this:

• the JvmImplementation class is inconsistent with the JvmVendorSpec class: it should in theory behave similarly: a spec should be provided, so that we can use other implementations than J9. Currently, it's impossible to request something different than J9, even if custom JDKs offer alternatives.
• the JvmVendorSpec has been updated so that we can query if a vendor matches the spec. Without this, it's barely impossible for a provisioner to tell if it's compatible or not
• the current implementation selects the first one which lists at least a candidate. This probably needs to be changed as typically this forces the AdoptOpenJDK provisioner to be put last in the list (because it always answers "yes, I have candidates" even if in practice we don't know if it's going to be available)
• there is now an injectable service to provide downloads (similar to JdkDownloader with a more generic signature): RemoteResourceService
• some complexity comes from the fact we want to report the name of the downloaded JDK before we actually start downloading it, and that we want to provide the provisioning service with the location where to write the file (so that it lives in cache)

This should make it possible for projects like @joschi 's Java Metadata to provide a list of candidates based on the contents of the JSON file, and perform the download lazily.

Contributor Checklist

• Review Contribution Guidelines
• Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
• Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
• Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
• Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
• Provide unit tests (under <subproject>/src/test) to verify logic
• Update User Guide, DSL Reference, and Javadoc for public-facing changes
• Ensure that tests pass sanity check: ./gradlew sanityCheck
• Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation
• Recognize contributor in release notes