On Fri, 25 Sep 2026 23:07:35 GMT, Michael Strauß <[email protected]> wrote:
> The runner fails precisely because the new subproject uses Gradle's Java
> toolchain feature. It requests JDK 25, but the runners don't have that; they
> only have JDK 26. `JAVA_TARGET_VERSION` is 25
It can't be the full reason because otherwise all runners would have failed the
same way.
I did some debugging by changing the workflow file. The problem is as I
suspected, the runners are misconfigured. Linux and Mac have various JDK
installations on them, Windows has only one. Here is the info:
### Windows x64
> Task :javaToolchains
+ Options
| Auto-detection: Enabled
| Auto-download: Enabled
+ Oracle JDK 26 (26.0.2+10-55)
| Location: C:\Users\runneradmin\bootjdk\jdk-26.0.2
| Language Version: 26
| Vendor: Oracle
| Architecture: amd64
| Is JDK: true
| Detected by: Current JVM
### macOS aarch64
> Task :javaToolchains
+ Options
| Auto-detection: Enabled
| Auto-download: Enabled
+ Eclipse Temurin JDK 11 (11.0.32.1+1)
| Location:
/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.32-101/arm64/Contents/Home
| Language Version: 11
| Vendor: Eclipse Temurin
| Architecture: aarch64
| Is JDK: true
| Detected by: MacOS java_home
+ Eclipse Temurin JDK 17 (17.0.20.1+1)
| Location:
/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/17.0.20-101/arm64/Contents/Home
| Language Version: 17
| Vendor: Eclipse Temurin
| Architecture: aarch64
| Is JDK: true
| Detected by: MacOS java_home
+ Eclipse Temurin JDK 21 (21.0.12.1+1-LTS)
| Location:
/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.12-101.0/arm64/Contents/Home
| Language Version: 21
| Vendor: Eclipse Temurin
| Architecture: aarch64
| Is JDK: true
| Detected by: MacOS java_home
+ Eclipse Temurin JDK 25 (25.0.4.1+1-LTS)
| Location:
/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/25.0.4-101.0/arm64/Contents/Home
| Language Version: 25
| Vendor: Eclipse Temurin
| Architecture: aarch64
| Is JDK: true
| Detected by: MacOS java_home
+ Oracle JDK 26 (26.0.2+10-55)
| Location: /Users/runner/bootjdk/jdk-26.0.2.jdk/Contents/Home
| Language Version: 26
| Vendor: Oracle
| Architecture: aarch64
| Is JDK: true
| Detected by: Current JVM
### Linux x64
> Task :javaToolchains
+ Options
| Auto-detection: Enabled
| Auto-download: Enabled
+ Eclipse Temurin JDK 8 (1.8.0_504-b01)
| Location: /usr/lib/jvm/temurin-8-jdk-amd64
| Language Version: 8
| Vendor: Eclipse Temurin
| Architecture: amd64
| Is JDK: true
| Detected by: Common Linux Locations
+ Eclipse Temurin JDK 11 (11.0.32.1+1)
| Location: /usr/lib/jvm/temurin-11-jdk-amd64
| Language Version: 11
| Vendor: Eclipse Temurin
| Architecture: amd64
| Is JDK: true
| Detected by: Common Linux Locations
+ Eclipse Temurin JDK 17 (17.0.20.1+1)
| Location: /usr/lib/jvm/temurin-17-jdk-amd64
| Language Version: 17
| Vendor: Eclipse Temurin
| Architecture: amd64
| Is JDK: true
| Detected by: Common Linux Locations
+ Eclipse Temurin JDK 21 (21.0.12.1+1-LTS)
| Location: /usr/lib/jvm/temurin-21-jdk-amd64
| Language Version: 21
| Vendor: Eclipse Temurin
| Architecture: amd64
| Is JDK: true
| Detected by: Common Linux Locations
+ Eclipse Temurin JDK 25 (25.0.4.1+1-LTS)
| Location: /usr/lib/jvm/temurin-25-jdk-amd64
| Language Version: 25
| Vendor: Eclipse Temurin
| Architecture: amd64
| Is JDK: true
| Detected by: Common Linux Locations
+ Oracle JDK 26 (26.0.2+10-55)
| Location: /home/runner/bootjdk/jdk-26.0.2
| Language Version: 26
| Vendor: Oracle
| Architecture: amd64
| Is JDK: true
| Detected by: Current JVM
Looks like the Linux and Mac runners come with preinstalled Temurin
installations. This is dangerous since the additional JDKs might be used in
some unintended way. Somewhat ironically, the Windows runner is the only
correct one.
@kevinrushforth this looks to me like a proper bug with the Linux and Mac
runners' setup. In general, the workflow setup does a lot of manual handling
for jobs that can be done automatically, e.g., with GH's official
[setup-java](https://github.com/actions/setup-java) and with Gradle's
[setup-gradle](https://github.com/gradle/actions). If the licensing checks
permit, I'd use them instead (and I see that GH's `checkout` action is used, so
there's some precedent here).
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).
The correct constant is the major ("feature") version of
`jfx.build.jdk.version=26.0.2`, which is what the main build uses.
Alternatively, if #2294 is integrated prior to this issue, then we can remove
the toolchain configuration here and rely on the one in the main build.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/2156#issuecomment-5846335472
