Le 2025-05-25 à 13 h 28, Elliotte Rusty Harold a écrit :
Can you be more specific? Is there some code we need to produce or
compile that we cannot compile with Java 8?
Yes. Maven 4 core and the compiler plugin 4.0.0-beta already got the
following Java 9+ dependencies:
* MODULE_PATH, UPGRADE_MODULE_PATH, PATCH_MODULE_PATH,
ANNOTATION_PROCESSOR_MODULE_PATH enumeration values of
javax.tools.StandardLocation (used in
org.apache.maven.api.JavaPathType).
* java.lang.module.ModuleDescriptor (used in
org.apache.maven.impl.DefaultDependencyResolverResult).
* javax.tools.StandardJavaFileManager.setLocationForModule(...) and
related methods (used in compiler plugin).
* Maybe more that I forgot.
We are still trying to figure out how to lay out code for multi-module
projects.
The choice is left to users. The discussion was only about the *default*
layout, and the difficulty was not in JPMS per se but in finding a
compromise with Maven 3 habits.
That we haven't yet figured this out and haven't really needed to.
suggests that maybe multi-module projects aren't all that important in
the real world.
I think that the problem is rather widespread misunderstanding about
JPMS, in part by lack of user's experience since JPMS is difficult to
leverage fully in Maven 3 and Gradle. This is suggested by the fact that
we see peoples blaming JPMS for what are Maven and Gradle problems (lack
of control on class-path versus module-path, way to compile tests). See
also next paragraph.
JPMS has pretty much failed. It's not clear it was ever needed in the
first place.
Before to said that JPMS failed, let first give it a real chance with
real support in Maven 4. Needs exist without peoples realizing it. For
example, Maven recently puts in place a mechanism based on ClassLoader
for isolating the dependencies of a plugin from other plugins (e.g. if a
plugin uses Log4J, do not bring LogJ4 in the environment of all other
plugins). If Maven was using JPMS, this isolation would be supported
natively with no need for extra complexity (except in case of
conflicting versions, but we can still manage with java.lang.ModuleLayer).
Another need seen in my work is reducing the "class-path hell" such as
dependencies put twice with different versions. Not everyone use the
Maven enforcer plugin. This is another example of service that could be
handled natively by JPMS instead of adding another layer of complexity.
It has been reported that JPMS improves JVM startup time, but I didn't
benchmark myself.
That said, I would like to be able to support multi-module builds, but
what exactly can't we do without requiring Java 11?
Using the module-specific API of javax.tools for compilation and javadoc
generation.
There's plenty of Java 8 code that is fully compatible with JPMS.
They can be partially compatible with some work duplication. For
example, services declared in META-INF/services must be repeated in
module-info, with a risk of inconsistency if the developer updates the
former but forgot to also update the latter. But if, for example, an
application loads JAR files dynamically, then it cannot be fully
compatible with JPMS without using Java 9+ API. Using
java.lang.ClassLoader alone loads the JAR file as if it was on the
class-path. If the developer wants to load the JAR file as if it was on
the module-path, she needs to use java.lang.ModuleLayer.
All that said, if you can demonstrate in detail that Java 11 is
required for Maven to build projects that use JPMS, and we have a plan
for addressing everything else needed to support multi-module builds,
then I would find that a compelling reason to require Java 11.
I have more than a plan: it is almost done for the compiler plugin, and
I started to look at the other plugins. Java 11 is required, we need all
the API listed at the beginning of this email, this is already
integrated in Maven 4 + compiler plugin 4.0.0-beta and already deployed
on Maven central (the deployed versions do not yet offer full JPMS
support however). The compiler plugin on the master branch already
offers full multi-modules support for compiling the main code. The work
is also completed for compiling the test code, but that work has not
been merged yet. Details there:
* https://github.com/Geomatys/maven/wiki
* https://github.com/Geomatys/maven-compiler-plugin/wiki
We need to also update the resources, javadoc and Surefire. I'm working
on that.
Java 16+ for starting the migration to records.
As much as I would like to rip out Modello and chuck it into the
Mariana trench, I don't think that's likely to happen. Consequently
this is a non-starter.
The plan is not te remove Modello, but to modify the code that it
generates. There is also various classes not generated by modello that
would be done manually.
Martin
