GeezerVison

[agent] Before merge: whichBin rejects even with nothrow: true when nothing is found: it calls resolveBinPathSync(null) and fails with ENOENT … realpath 'null'. With JAVA_HOME unset and no java on PATH, the whole facts run aborts, in exactly the setup where discovery (e.g. JAVA_HOME_17_X64 on a runner) should have picked a JDK. A test for it: expect(await currentJavaInstallation({ PATH: path.join(root, 'empty') })).toBeUndefined().

[agent] Before merge: Gradle-provisioned JDKs mostly sit one level deeper than this looks, e.g. ~/.gradle/jdks/eclipse_adoptium-17-aarch64-os_x.2/jdk-17.0.12+7/ and oracle_corporation-21-aarch64-os_x/jdk-21.0.2.jdk/Contents/Home. Only some vendors (bellsoft, azul) unpack flat. This descends one level into children that aren't JDKs themselves. To test it, add fakeJdk(path.join(jvm, 'eclipse_adoptium-11-x64-linux', 'jdk-11.0.24+8'), '11.0.24') to the discovery test. It lands after jdk17, because the default symlink sorts first.

[agent] Before merge: A current JDK we can't identify is treated as one that doesn't fit, so we switch away from a JDK that probably works, and the log says the tool "does not run on" it. On macOS without JAVA_HOME, /usr/bin/java is a launcher stub, not a symlink, so current is always undefined there and every Gradle wrapper or sbt run switches JDK. The same happens when JAVA_HOME points at a JDK without a release file. I'd switch only when the current JDK is known not to fit, or when there is no Java at all (no JAVA_HOME, nothing on PATH), and keep it when a Java exists but can't be identified. For the macOS case, /usr/libexec/java_home gives the real home.

[agent] Before merge: This makes every release after the newest table entry unbounded, not just new majors. Gradle 9.1.0 caps at 25, but 9.1.1 or 9.2 runs on anything, and likewise sbt 1.9.0 versus 1.9.1. Once a JDK 26 default arrives, a Gradle 9.2 project won't be moved off it, which is the failure this PR fixes. One option: only a newer major is unbounded, and later releases in the same line keep the newest known limit. The cost is an occasional unnecessary switch to an older installed JDK until the table catches up, which seems the safer direction. The test change is in the thread on java-home.test.mts:65.

[agent] Before merge (goes with the javaRange thread at java-home.mts:82): the test update if you take that suggestion.

[agent] Nit: same array-destructuring convention.

[agent] Nit: "LTS Java releases only" reads as if every LTS has a row, so a reader will wonder whether 21 was forgotten. It's covered because 21 and 25 share the same first sbt release, which may be worth saying.

[agent] Nit: The table caps 0.13.x at 11, but your own measurements show 0.13.18 starting on 17. Since 1.0 to 1.2 don't, a monotonic table can't express that. It's harmless (at worst an unneeded switch to 11), but the comment could mention it so nobody "fixes" the table later.

[agent] Nit: This test stubs process.env, so discovery also scans the host's real JDK folders. That's why it can only assert "not 25" and has to parse the picked release file. Passing searchDirs through (or an explicit javaHome option, as in the run.mts:184 thread) would let it assert toBe(jdk21).

[agent] Nit: current and toolVersion are only used for the log message in withBuildJavaHome. Returning just the picked installation, with the message built here, would drop this comment, the nested ternary in the log, and a test that pins the log's inputs as API.