Proof of concept for installation properties

[jbartok]

First attempts at a new API for Toolchain specs.

[DPUkyle]

Can you also share the dummy project we created to test this?

[jbartok]

Can you also share the dummy project we created to test this?

java {
  toolchain {
    languageVersion = JavaLanguageVersion.of(11)
    installationProperties = withProperties {
      property JvmInstallationPropertiesSpec.JvmInstallationProperty.VM_VERSION, contains("11.0.12")
    }
  }
}

[bric3]

Hi,

Thank you very much for taking this into consideration !

Looking at the code I ask myself a few observations

1. The current angle is using the vocabulary of properties, I wonder why not reusing the notion of dimensions that is already used by the dependencies. What about this classification (it is a very naive one)

   • Incubating JDK: CRaC (currently variant of JDK17), Loom (currently variant of JDK18), Panama Foreign (Current variant of JDK17), etc. mutually exclusive
   • Patches: DCEVM, JCEF, etc. patches can be additive
   • Debug build, eg fastdebug
   • Java version (eg Java 8, Java 11, Java 17, etc)
   • Vendors (Temurin, Azul, Amazon)
   • Runtime version (eg GraalVM 21.3.0, also Mandrel 21.3.0, JDK 11.0.13, JDK 17.0.1, etc.)

2. How those properties are acquired ? Some information can only be obtained by running the java --version, but maybe this is not enough in certain case. Which leads me to my second point.

3. It's not advisable for Gradle to cover every cases out there, and to improve future-proof-ness, the property retrieval should be extendable.

   JvmInstallationMetadata is currently internal. Maybe there's a way to introduce some contributor to these metadata.

4. This leads me to how to validate the property, do all these properties will be String ?

---

For reference here's the builds that I am playing with

• A local build of the JDK, with my custom changes
• Builds from jdk.java.net/ (Panama especially)
• Builds from https://builds.shipilev.net/ (or sexyjdk.com works too since Joshua Bloch created this domain)
• JetBrains JVM https://github.com/JetBrains/JetBrainsRuntime/releases because I need their JCEF and DCEVM patches for some desktop application development.
• And distributions from asdf-vm (GraalVM)

And I am not even concerned (yet) by different architectures.

[ljacomet]

@bric3 I finally made an issue to describe our objective here. Could you take a look at #18896 and copy your comment / questions over there so they could be answered in that (better) context?

[bric3]

@ljacomet Thank you I will do it.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be closed if no further activity occurs. If you intend to work on this pull request, please ask the team to reopen the PR or push a new PR. Thank you for your contributions.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be closed if no further activity occurs. If you intend to work on this pull request, please ask the team to reopen the PR or push a new PR. Thank you for your contributions.

[stale]

This pull request has been automatically closed due to inactivity. If you are still interested in contributing this, please ensure that it is rebased against the latest branch (usually master), all review comments have been addressed and the build is passing.

[bric3]

@ljacomet @jbartok Is this one stale (or closed) ?

[ljacomet]

This is a topic we hope to resume work on soon. I am not going to eagerly re-open this one though as the implementation may end up being quite different. If we end up reusing this, it can be re-opened then.