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

--0000000000004a6bcf06582af88b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=BBt 2026 =C3=A0 21:10, Maarten Mulders <[email protected]=
rg> a
=C3=A9crit :

> 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 hav=
e.
>
> Thanks,
>
> Maarten
>
> On August 3, 2026 at 17:14, Matthias B=C3=BCnger 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.sourc=
e>
> >> (or uses <release>, <targetVersion>, or compiler plugin
> >> <configuration><source>), and you run Maven with JDK 21 =E2=80=94 whic=
h dropped
> >> --source 6 support =E2=80=94 the build fails with a cryptic javac erro=
r. 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 =E2=80=94 first in configured toolchains (toolchains.xm=
l),
> >> 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 t=
he
> >> running JDK genuinely cannot handle the project's source level. Normal
> >> builds are completely unaffected.
> >>
> >> Design decisions worth discussing
> >>
> >> 1. Filesystem discovery =E2=80=94 The discoverer scans well-known loca=
tions
> >> (SDKMAN, IntelliJ .jdks/, Gradle, jEnv, JBang, asdf, mise, OS-specific
> >> paths like /usr/lib/jvm). Version is read from the JDK release file =
=E2=80=94 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 =E2=80=94 We read the source level from mult=
iple
> >> 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 =E2=80=94 When multiple compatible JDK=
s 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 =E2=80=94 The v3 ToolchainManagerFactory bridge now pa=
sses the
> >> discoverer through, so plugins using the v3 API also benefit. This fel=
t
> >> important for the transition period.
> >>
> >> CI is green on all platforms (Linux/macOS/Windows =C3=97 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]
>
>

--=20
------------------------
Guillaume Nodet

--0000000000004a6bcf06582af88b--