Re: [DISCUSS] Automatic JDK toolchain selection when running JDK is incompatible (4.1.0)

Maarten Mulders <[email protected]> Mon, 3 Aug 2026 21:10:03 +0200
Newsgroups gmane.comp.jakarta.turbine.maven.devel
Organization Apache Software Foundation
Message-ID <[email protected]>
Hi,

Agree with Matthias. Earlier ideas on "troubleshooting common errors 
through Maven Core" have been rejected for reasons like "people should 
read the error messages and take corresponding action, rather than Maven 
trying to diagnose or even repair it". It would be strange to now 
include such features. I would prefer having clear(er) error messages if 
that is the source of problem.

Also, I see many people blindly ignore warnings, so that would 
contribute to the scenario that Matthias outlined: "it works on my 
machine", while in fact I ignored the warning that says Maven switched 
to an auto-discovered JDK 11 that someone else on my project does not have.

Thanks,

Maarten

On August 3, 2026 at 17:14, Matthias Bünger wrote:
> Hi,
>
> I'm not convinced in trying to "fix" configuration errors in users 
> system/project from the "shadows". I think a clear error (and if 
> possible giving information what's wrong/how to fix) supports the user 
> more in really fixing the problem. Otherwise we support "it worked on 
> my machine". I can also think that it's massively increasing 
> maintenance effort on our side due question why it works here, but not 
> there or paths to look at on different OS.
>
> Matthias
>
> Am 03.08.2026 um 14:18 schrieb Guillaume Nodet:
>> Hi all,
>>
>> I've opened a draft PR for a quality-of-life feature in Maven 4.1.0:
>> automatic JDK toolchain selection when the running JDK cannot compile 
>> the
>> project's declared source/release level.
>>
>> PR: https://github.com/apache/maven/pull/12633
>>
>> The problem
>>
>> When a project declares <maven.compiler.source>6</maven.compiler.source>
>> (or uses <release>, <targetVersion>, or compiler plugin
>> <configuration><source>), and you run Maven with JDK 21 — which dropped
>> --source 6 support — the build fails with a cryptic javac error. The 
>> user
>> has to figure out they need to install a compatible JDK and either
>> configure toolchains.xml or add the maven-toolchains-plugin to their 
>> build.
>> This is a frequent stumbling block, especially when maintaining older
>> projects.
>>
>> The solution
>>
>> Maven now automatically detects the incompatibility and searches for a
>> compatible JDK — first in configured toolchains (toolchains.xml), 
>> then by
>> lazily discovering JDK installations on the filesystem. If a 
>> compatible JDK
>> is found, it's selected as the compilation toolchain and a warning is
>> emitted:
>>
>> [WARNING] Project requires --source 6 which is not supported by JDK 21.
>> [WARNING] Automatically selected JDK 11 (discovered at
>> /usr/lib/jvm/java-11) for compilation.
>>
>>
>> This is a zero-cost feature: the auto-selection logic only runs when the
>> running JDK genuinely cannot handle the project's source level. Normal
>> builds are completely unaffected.
>>
>> Design decisions worth discussing
>>
>> 1. Filesystem discovery — The discoverer scans well-known locations
>> (SDKMAN, IntelliJ .jdks/, Gradle, jEnv, JBang, asdf, mise, OS-specific
>> paths like /usr/lib/jvm). Version is read from the JDK release file — no
>> java processes are spawned. This is essentially what
>> maven-toolchains-plugin's ToolchainDiscoverer does, but moved into 
>> core and
>> made lazy. Does this make the plugin's auto-discovery redundant? 
>> Should we
>> deprecate it?
>>
>> 2. Source level detection — We read the source level from multiple 
>> places
>> in priority order: Model 4.1.0 <source><targetVersion>, then
>> maven.compiler.release/maven.compiler.source properties, then compiler
>> plugin <configuration><release>/<source>. Is this the right 
>> precedence? Are
>> there other places we should check?
>>
>> 3. "Newest compatible" strategy — When multiple compatible JDKs are 
>> found,
>> we pick the newest one (highest major version that still supports the
>> required source level). The rationale is that a newer JDK gives better
>> performance and diagnostics. Should this be configurable?
>>
>> 4. Compat layer — The v3 ToolchainManagerFactory bridge now passes the
>> discoverer through, so plugins using the v3 API also benefit. This felt
>> important for the transition period.
>>
>> CI is green on all platforms (Linux/macOS/Windows × JDK 17/21/25).
>>
>> Feedback and reviews welcome.
>>
>> Guillaume
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>