[Martin Torp (mtorp)]

Older Gradle and sbt versions refuse to start on newer JDKs. So a machine whose default JDK is newer than the project's pinned build tool fails to generate Socket facts, even when a suitable JDK is installed next to it. Managed reachability scans want to move their default JDK to 25, and Gradle 8 projects are where that breaks.

When facts generation runs a Gradle wrapper or sbt build, the CLI now reads the version the project pins and checks it against the JDK in JAVA_HOME (or the java on PATH). If the build tool doesn't run on that JDK, the build runs on the newest installed JDK it does run on, and the CLI logs which one:

ℹ Running gradle 8.14.3 on Java 21 at /usr/lib/jvm/temurin-21, since it does not run on Java 25 at /usr/lib/jvm/temurin-25.

• Versions: the Gradle version comes from gradle/wrapper/gradle-wrapper.properties and the sbt version from project/build.properties. A Gradle wrapper given as the bin, such as ../gradlew or an absolute path, is read from the gradle/wrapper folder next to it. A Gradle on PATH, any other custom bin and Maven keep the current JDK.
• Supported ranges: Gradle follows its compatibility matrix. Gradle 9 needs at least 17. sbt needs 1.3 for Java 17 and 1.9 for Java 21 and 25, which I measured (table below). A version newer than the table knows is allowed on any JDK.
• Discovery: JDKs are found by their release file in the children of /usr/lib/jvm, /usr/lib64/jvm, /usr/java and /opt/java, in SDKMAN, in ~/.gradle/jdks and ~/.jdks, in macOS JavaVirtualMachines bundles, and through the JAVA_HOME_<release>_<arch> variables GitHub and Azure runners set.
• What stays the same: a javaHome from socket.json is used as is. If no installed JDK fits, the build runs on the current one, as it did before.

Where each build tool started and resolved a Guava dependency (Temurin in Docker):

Build tool	8	11	17	21	25
Gradle 4.10.3, 5.6.4	✅	✅
Gradle 6.9.4		✅	❌
Gradle 7.6.4		✅	✅		❌
Gradle 8.5, 8.14.3			✅	✅	❌
Gradle 9.0.0	❌		✅		✅
sbt 0.13.18	✅	✅	✅
sbt 1.2.8		✅	❌
sbt 1.3.13, 1.5.8			✅	❌	❌
sbt 1.8.3				❌	❌
sbt 1.9.0, 1.9.9, 1.10.11					✅

Testing: unit tests for version parsing, ranges, discovery and selection use real temp-dir JDK layouts. A run.mts test checks that the spawned build gets the picked JAVA_HOME and that a configured one is kept. End to end, I ran the built CLI in an image with JAVA_HOME set to Temurin 25 and all five JDKs installed. socket manifest gradle on a Gradle 8.14.3 wrapper project ran on 21, and socket manifest scala on an sbt 1.5.8 project ran on 17. Both wrote facts containing the dependency. Without this change both builds fail to start on 25.

Follow-ups, not in this PR:

• A retry on a recognisable failure, for example a toolchain languageVersion that isn't installed.
• Per-project JDK hints such as .sdkmanrc, .tool-versions and actions/setup-java.
• A port to main.

Expected reviewer effort: High-level design decisions

---

Note

Medium Risk
Changes which JDK runs Gradle/sbt manifest builds when the default is incompatible; wrong compatibility tables or discovery could pick a bad JDK, though explicit javaHome/JAVA_HOME still wins.

Overview
When generating Socket facts via a Gradle wrapper or pinned sbt build, the CLI now detects a JDK/JAVA_HOME mismatch with the project's Gradle or sbt version and, if needed, runs the build on the newest installed JDK that version supports—logging the switch—instead of failing on a default JDK that is too new or too old.

A new java-home helper reads wrapper/build.properties versions, applies Gradle and sbt Java compatibility ranges, discovers JDKs under common install paths and CI JAVA_HOME_* variables, and runManifestScript / enumerateWorkspaces set JAVA_HOME on the spawned process when auto-selection applies. Maven, non-wrapper Gradle, and an explicit JAVA_HOME in options (including socket.json javaHome) are unchanged; if no suitable JDK is found, behavior stays as before.

isBuildToolWrapper was added so Gradle version detection only runs for wrapper invocations. Unit and integration-style tests cover parsing, ranges, discovery, selection, and spawned env.

^{Reviewed by Cursor Bugbot for commit 8b2e827. Configure here.}