Auto-select JDK toolchain when running JDK cannot compile source level - #12633
Draft
gnodet wants to merge 8 commits into
Draft
Auto-select JDK toolchain when running JDK cannot compile source level#12633gnodet wants to merge 8 commits into
gnodet wants to merge 8 commits into
Conversation
…'s source level When the running JDK does not support the project's --source/--release level (e.g., JDK 17 cannot compile --source 6), Maven now automatically searches configured toolchains for a compatible JDK and selects it for compilation. The auto-selection hooks into getToolchainFromBuildContext() — when no explicit toolchain has been set via maven-toolchains-plugin, the manager checks the project's targetVersion (Model 4.1.0) or legacy properties (maven.compiler.release, maven.compiler.source) against the running JDK's supported source levels. If the running JDK cannot handle the required level, it picks the newest compatible JDK from configured toolchains, caches the selection, and emits a warning. Key changes: - New JdkSourceLevelSupport utility mapping JDK versions to supported --source levels based on the javac retirement schedule (JEP 182) - DefaultToolchainManager.getToolchainFromBuildContext() now falls back to auto-selection for "jdk" type when no explicit toolchain is stored - Reads source level from Model 4.1.0 <source><targetVersion> elements and legacy maven.compiler.release/source properties - Prefers the newest compatible JDK from configured toolchains Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Two ITs verify the auto-selection behavior end-to-end through Maven's compat bridge: - testAutoSelectToolchainWhenSourceLevelUnsupported: project requires source 6 (unsupported by JDK 12+), verifies Maven auto-selects a compatible JDK 11 toolchain and logs a warning - testNoAutoSelectWhenSourceLevelSupported: project requires source 11 (supported by JDK 12+), verifies no auto-selection occurs Also adds debug logging to the auto-selection path for diagnostics. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
elharo
reviewed
Jul 30, 2026
elharo
left a comment
elharo
left a comment
Contributor
There was a problem hiding this comment.
Good idea. does this need an issue to get picked up in the release notes?
Contributor
Author
No, an issue and a PR are similar in all points, but the fact that an issue does not have code. |
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When no compatible JDK is found in toolchains.xml, Maven now lazily discovers JDKs from the filesystem by scanning well-known locations: JAVA*_HOME env vars, SDKMan, IntelliJ .jdks/, Gradle, jEnv, JBang, asdf, mise, and OS-specific paths (/usr/lib/jvm, etc.). Discovery only runs on the failure path (running JDK incompatible AND no configured toolchain matches), so normal builds pay zero cost. JDK version is read from the release file (no java process spawned). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace direct System.getProperty/System.getenv calls with the properties map from Session.getSystemProperties(), where env vars are available as "env.VAR_NAME" entries. This follows Maven's convention of accessing environment through the Session and makes the discoverer fully testable without relying on JVM global state. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…nd JDK discovery Three fixes for automatic JDK toolchain selection: 1. Read source level from compiler plugin configuration: many projects set <source> and <release> directly in the maven-compiler-plugin <configuration> block rather than as properties. Added getSourceLevelFromCompilerPlugin() to check both <release> and <source> elements. 2. Pass JdkToolchainDiscoverer to compat layer: ToolchainManagerFactory was creating DefaultToolchainManager without the discoverer, so old plugins going through the compat layer could detect incompatibility but had no discoverer to find alternative JDKs. 3. Scan JAVA_HOME parent directory for sibling JDKs: in CI and container environments, multiple JDKs are often installed as siblings (e.g. /toolchain/jdk-8, /toolchain/jdk-11, /toolchain/jdk-21). Added parent directory scanning from each JAVA*_HOME env var. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The gh-11055 DI service injection IT calls new DefaultToolchainManager(Map.of()) from outside the package, so the single-arg Map constructor must be public. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…nd IT harness The gh-11055 DI service injection IT calls new DefaultToolchainManager(Map.of()) from outside the package, and the compat layer ToolchainManagerFactory calls the 3-arg constructor (factories, discoverer, logger). All constructors must be accessible from outside the package. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
--source/--releaselevel (e.g., JDK 21 cannot compile--source 6), Maven now automatically searches for a compatible JDK and selects it for compilationtoolchains.xml), then lazily discovers JDKs from the filesystem — normal builds pay zero costDefaultToolchainManager.getToolchainFromBuildContext()as a fallback when no explicit toolchain is set viamaven-toolchains-plugin<source><targetVersion>elements and legacymaven.compiler.release/maven.compiler.sourcepropertiesImplementation
Auto-selection (
DefaultToolchainManager)Enhanced
getToolchainFromBuildContext()with a two-stage fallback:maven-toolchains-plugin), returns it immediately (no change)"jdk"type only: checks the project's required source level against the running JDKtoolchains.xml) for the newest compatible JDKJdkToolchainDiscovererLazy filesystem discovery (
JdkToolchainDiscoverer)Scans well-known locations for JDK installations:
JAVA_HOME,JAVA*_HOME(e.g.JAVA11_HOME),java.homesystem property~/.sdkman/candidates/java), IntelliJ (~/.jdks), Gradle (~/.gradle/jdks), jEnv, JBang, asdf, Jabba, mise, Maven (~/.m2/jdks)/usr/lib/jvm,/opt/java), macOS (/Library/Java/JavaVirtualMachineswithContents/Home), Windows (C:\Program Files\Java, Adoptium, Zulu, Corretto)JDK version is read from the
releasefile (present since JDK 9) — nojavaprocesses are spawned. Results are cached in memory after first discovery.Source level compatibility (
JdkSourceLevelSupport)Maps JDK major versions to their supported
--sourcelevels, based on the javac retirement schedule (JEP 182):Test plan
JdkSourceLevelSupportTest: 14 tests covering JDK version → source level mapping, normalization of legacy formats (1.5→5,1.8.0_392→8), dotted versions (21.0.1→21), invalid inputsJdkToolchainDiscovererTest: 15 tests covering release file parsing (JDK 8/11/17 formats, missing/malformed files), JDK home validation, macOS bundle resolution, ToolchainModel building, cachingDefaultToolchainManagerTest: 17 tests covering auto-selection logic, discovery fallback, explicit toolchain precedence, legacy property detectiontestAutoSelectToolchainWhenSourceLevelUnsupported: project declaressource=6, JDK 12+ running → auto-selects JDK 11testNoAutoSelectWhenSourceLevelSupported: project declaressource=11, JDK 12+ running → no auto-selectionmaven-impltest suite passes (580 tests, 0 failures)🤖 Generated with Claude Code