On Sat, 5 Sep 2026 12:28:05 GMT, Nir Lisker <[email protected]> wrote:
>> Adds the [Java >> Toolchain](https://docs.gradle.org/current/userguide/toolchains.html#sec:using-java-toolchains) >> to replace manual executions: >> >> | Old | New >> |------|------| >> | `JAVA` | >> [JavaLauncher](https://docs.gradle.org/current/javadoc/org/gradle/jvm/toolchain/JavaLauncher.html) >> | >> | `JAVAC` | >> [JavaCompiler](https://docs.gradle.org/current/javadoc/org/gradle/jvm/toolchain/JavaCompiler.html) >> | >> | `JAVADOC` | >> [JavadocTool](https://docs.gradle.org/current/javadoc/org/gradle/jvm/toolchain/JavadocTool.html) >> | >> >> ## Instructions for reviewers >> >> The build runs on Windows and Linux (Ubuntu), but the analysis was done on >> Windows. >> >> ### JVM detection and selection >> The toolchain selects the JDKs to use based on all those that are made >> available to it. As detailed in the link above, JDKs can come from various >> sources on the user machine, including being auto-provisioned. The daemon >> JDK is always available (usually `JAVA_HOME`), and `gradle.properties` made >> `JDK_HOME` available in #2240. >> Selection of the toolchain build/worker JDK from all available ones is done >> internally (as detailed in the link) based on the restrictions configured in >> the toolchain. I have restricted the major version to that of >> `jdkVersionInfo` (exact version, not minimum), which is determined by the >> *build file's JDK resolution*: >> >> def envJavaHome = cygpath(System.getenv("JDK_HOME")) >> if (envJavaHome == null || envJavaHome.equals("")) envJavaHome = >> cygpath(System.getenv("JAVA_HOME")) >> def javaHome = envJavaHome == null || envJavaHome.equals("") ? >> System.getProperty("java.home") : envJavaHome >> >> However **the selected toolchain JDK might not be the same as the resolved >> build's JDK**. The toolchain always prefers the daemon JVM to avoid forking, >> so if it meets the restrictions, it's selected. Consider the following >> scenarios: >> >> | `JAVA_HOME` | `JDK_HOME` | Selection >> | >> |----------------|---------------|------------------------------------------------------| >> | 25 | 26 | `JDK_HOME` - only it passes the >> restrictions | >> | 26 | 25 | `JDK_HOME` - only it passes the >> restrictions | >> | 25/26 Path A | 25/26 Path B | `JAVA_HOME` - internal toolchain preference >> >:( | >> | 25/26 Path A | 25/26 Path A | `JAVA_HOME`==`JDK_HOME` >> | >> >> For local testing: >> 1. Stop the daemon with `gradlew --stop`. >> 2. Show the ... > > Nir Lisker has updated the pull request incrementally with one additional > commit since the last revision: > > Add toolchain also for root > One thing I noticed, but this might be expected? The following command does > not work anymore: > > ```java > bash gradlew --stop > env -u JDK_HOME JAVA_HOME=.../java25 bash gradlew \ > -PJDK_HOME=.../java26 \ > -Porg.gradle.java.installations.auto-detect=false \ > :base:compileJava -i --rerun > ``` > > Error: > > ``` > Cannot find a Java installation on your machine (Linux 7.2.7-1-cachyos amd64) > matching: > {languageVersion=26, vendor=any vendor, implementation=vendor-specific, > nativeImageCapable=false}. > Toolchain download repositories have not been configured. > ``` > > So when I have JDK25 in my PATH but want to override it with `-PJDK_HOME` to > JDK26, it does not seem to work or am I doing it wrong? What I understand here is that you're settings `JAVA_HOME` to some JDK25, you have a(nother?) JDK25 in your PATH, and you're claiming you want to override `JDK_HOME` using a `-P` arg to a JDK26, but where is the overridden `JDK_HOME`? Simply having a JDK on the PATH doesn't do anything when `auto-detect=false`. I suggest that you run `gradlew javaToolchains` instead of `:base:compileJava -i --rerun` to see what Gradle finds. I suggest also trying with a set `JDK_HOME` without overriding it to make sure that the baseline works. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2294#issuecomment-5851091047
