On Sat, 26 Sep 2026 12:38:40 GMT, Nir Lisker <[email protected]> wrote:
> Back to the issue at hand, the build uses JDK 26, not JAVA_TARGET_VERSION, > which is 25. So the real fix here is to change the Java version in the > toolchain to 26. I had it on 25 because I thought that we build with N-1 > where N=26, but either we build with N or we switched to N=27 and I didn't > see (and still build with N-1). I'll reply with a subset of what I replied in an earlier comment: My suggestion of using JDK_TARGET_VERSION was wrong if that also affects what JDK is used (which it seems is does). 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, we can either continue to use a forked Java like we currently do, or we could consider waiting until [PR 2294](https://github.com/openjdk/jfx/pull/2294) is integrated and use Java toolchain. Before either of these can happen, we need to know whether the Java toolchain can it satisfy 1 and 2: an explicit path set by and env variable and a different value for `--release`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2156#issuecomment-5848404193
