On Sat, 26 Sep 2026 17:34:42 GMT, Kevin Rushforth <[email protected]> wrote:
>> I don't want more projects using the incorrect path. It will increase the >> technical debt. > > Let's first separate "what needs to be done" from "how it is done". Here are > the requirements for something being wired up to the build: > > 1. It must use the JDK specified by "$JDK_HOME" -- not just "look for a > matching version", but "use this path". For GHA builds it means using the one > we download. It doesn't matter what JDKs might or might not be available to > the runners. Ditto for our closed CI builds. > 2. The value of `--release` (or alternatively, `--source` and `--target`) > needs to be JDK_TARGET_VERSION. > > Today, that means using the downloaded JDK 26 for compilation, and setting > `--release 25`. When we bump the minimum version to 26 then both will be the > same until we bump the boot JDK to 27, etc. > > So it looks like my suggestion of using JDK_TARGET_VERSION was wrong if that > also affects what JDK is used. > > I think @mstr2 has a point when he suggests that it might be premature to use > the Java toolchain, but we could still consider it as long as it can it > satisfy 1 and 2. 1. The details on how the toolchain selects the JDK are in https://github.com/openjdk/jfx/pull/2294, but in short, requirement 1 cannot be satisfied in all (corner) cases. For the GHA builds it's not an issue because they set `JAVA_HOME` and not `JDK_HOME`, so as long as a suitable JDK exists in `JAVA_HOME`, it will select it (and if it's not suitable, the build will fail, which is probably what you want). The case where `JDK_HOME` will not be selected is if `JAVA_HOME` is set to a different JDK that also matches the requirements (version, vendor...). It's a rather odd configuration to have 2 of the same JDK on the machine and set each to a different env var. 2. These can be set regardless of the toolchain, as shown [here](https://docs.gradle.org/current/userguide/toolchains.html#sec:release-flag-toolchain) (sections 2 and 3). > Today, that means using the downloaded JDK 26 for compilation, and setting > --release 25. When we bump the minimum version to 26 then both will be the > same until we bump the boot JDK to 27, etc. > So it looks like my suggestion of using JDK_TARGET_VERSION was wrong if that > also affects what JDK is used. Yes, so `--release` should be `JDK_TARGET_VERSION`, and the toolchain version should come from the build JDK version. In the main build, I see only `sourceCompatibility = JAVA_TARGET_VERSION`. > I think @mstr2 has a point when he suggests that it might be premature to use > the Java toolchain, but we could still consider it as long as it can it > satisfy 1 and 2. We could do it, but I didn't test that configuration. It will require removing the `if` check for this project, then the `java` configuration can be removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2156#discussion_r4113528320
