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

Hi Gerd, Guillaume,

Thank you for your summary and proposal, Gerd. I like the fact that your 
proposal focusses on "keeping things where they belong". I think it is a 
nice path forward!

Maarten

On 04/08/2026 23:51, Gerd Aschemann wrote:
> Hi Guillaume,
> 
> I share Matthias' and Maarten's reservation about Maven core "repairing"
> a misconfiguration from the shadows -- but the underlying need (building
> an older project on a modern JDK) is real and worth solving. I think the
> disagreement dissolves if we split it across three responsibilities
> instead of putting everything in core:
> 
> 1. Core = diagnose, don't repair.
>     When the running JDK cannot honour the requested source/release level,
>     emit one clear, actionable error: the max JDK that supports the level,
>     and a single command to fix it. That satisfies the "read the error and
>     act" position without a cryptic javac failure.
> 
> 2. Discovery + selection stays in maven-toolchains-plugin.
>     The plugin already owns this: `select-jdk-toolchain` discovers and
>     selects a matching JDK at build time, `display-discovered-jdk-toolchains`
>     and `generate-jdk-toolchains-xml` round it out, and 3.3.0 just extended
>     discovery (asdf, more Windows locations, dedup across env vars). Moving
>     the discoverer into core would duplicate -- and eventually orphan --
>     code the plugin is actively investing in. So to your question in the PR
>     ("does this make the plugin's discovery redundant?"): I'd argue the
>     opposite -- keep discovery in one place, the plugin, and have core only
>     diagnose.
> 
> 3. The real gap none of the current pieces fill: what to do when *no*
>     compatible JDK is installed at all.
>     This is where a "propose" (and, opt-in, "provision") capability would
>     help -- and it belongs in tooling, not core. Concretely, a new goal in
>     maven-toolchains-plugin that, given the required level, queries the
>     foojay Disco API for a matching distribution. Default output is
>     actionable only: an `sdk install java <id>` line and/or a download URL,
>     plus optionally writing the toolchains.xml entry. Actually downloading a
>     JDK stays opt-in and checksum-verified. This mirrors what Gradle already
>     does via its foojay-resolver convention, and foojay is vendor-neutral
>     (Temurin/Zulu/Liberica/Corretto/...).
> 
> Your mvnup idea fits cleanly on top: mvnup can write the <toolchain>
> declaration into the project using that same discover/propose engine, so
> the project becomes self-describing for the next contributor.
> 
> For the project-less case (no reactor at hand), the same proposal action
> would sit naturally in the Maveniverse Toolbox / mvnx family, which is
> already in this space (MWM came up on the #12646 thread).
> 
> Cheers,
> Gerd
> 
> 
>> On 3. Aug 2026, at 23:10, Guillaume Nodet <[email protected]> wrote:
>>
>> The starting point was to be able to build old projects with Maven 4.
>> Would enhancing mvnup to add a toolchain declaration on the project,
>> thereby leveraging the m-toolchain-p be a better solution ?
>>
>> Le lun. 3 août 2026 à 21:10, Maarten Mulders <[email protected]> a
>> écrit :
>>
>>> 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]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> -- 
>> ------------------------
>> Guillaume Nodet
> 
> --
> Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas)
> +49/173/3264070 -- [email protected] -- https://aschemann.net
> 
>