Advice + proposals regarding automodule naming

forax at forax at
Sat Jan 21 10:07:12 UTC 2017

----- Mail original -----
> De: "Robert Scholte" <rfscholte at>
> À: forax at
> Cc: jpms-spec-experts at, "Brian Fox" <brianf at>
> Envoyé: Vendredi 20 Janvier 2017 12:08:03
> Objet: Re: Advice + proposals regarding automodule naming


>>> In the <configuration> of the maven-compiler-plugin it is of course
>>> possible to define which jars belong on which path, but that would make
>>> it
>>> very hard to use and maintain.
>> but at the same time you have need a way to be able to see a plain old
>> jar as a modular jar (without being an automatic module) to ease the
>> transition.
>> Here i think you need the user to say, Maven help me to generate a
>> synthetic module (a synthetic module-info.class that will be injected in
>> the jar of the dependency)
>> from the information available in the pom of that plain old jar.
>> It's not clear to me if this is something that should be in the
>> configuration or in the dependency of the pom.
> I think we need to clarify the term "ease of transition". What are we
> expecting and why?
> It looks to me the expectation is that every current existing Java project
> should be able to have a module-info where every dependency is specified
> as a requirement. We all agree (and have accepted) that in case of split
> packages this will not work, so we drop a little in percentages. Brian and
> I will go one step beyond: you cannot require unnamed / automatic modules.
> Even if we are going to consider synthetic modules, that won't solve the
> problem. This would require the developer to specify the module name for
> all his requirements AND including the transitive ones. The latter is
> required because there's no way to pass this kind of information to
> depending projects.
> Stability is the keyword here, and the automatic modules cannot guarantee
> stability.

"no way to pass" -> another idea,
as a way to help the transition, you can ask module-info that contains the dependencies to also have a mapping between the jigsaw name and the Maven artifact id,
something like

import some.specific.maven.annotation.MavenDependency;

module myapp {
  requires guava;

Having a dependency in the source to some Maven specific annotations if maybe not that great, the other solution is to hijack an already existing annotation like @SuppressWarnings or @Since

module myapp {
  requires guava;

you will still need to requires all transitive dependencies but at least you have the association between a module name and the corresponding Maven artifact name.

> Some developers have asked me: why do we need this? Tools like Maven are
> already superb in selecting all required dependencies for both compile
> time and runtime. Results are stable. And those few times there are
> issues, I was able to fix it by adding or excluding dependencies.
> With the module-info the result should be at least as stable as done with
> Maven. In case of automodules you could think of 2 options: #1 add as
> requires AND configure aliases for this synthetic module AND all its
> transitive unnamed modules. #2 drop requires for this module. I know which
> one I would choose.

#2 is like the Python 2/Python 3 transition, i.e. you have to wait that all your dependencies to be jigsawified before you can using them in Maven.
Just yesterday, a team of my students have to downgrade their whole soft from Python 3 to Python 2 because they need to use some specific geometric object on top of PostGIS, something that was never ported to Python 3.

I think we (the Java community) can do better.

> Also keep in mind: Maven Central also started empty. I don't know which
> jar was the first, but I'm pretty sure it can still be used. Give it time
> for jars to become modules. Ease of transition is already there because
> applications can refer to jars containing a module-info file, even if they
> don't use it.

yes, very true,
the question is more, can we make it easier for someone that starts a new project just after the release of the java 9 and before all its dependencies contains a module-info.

>>> For example: for test-compile I could have added a parameter called
>>> "moduleName" and use this value for the -Xmodule: argument. I've decided
>>> not to do so, because the name is already specified in the module-info.
>>> For me it was kind of frustrating that one assumed the name of the
>>> module
>>> was a given fact, which implied I had to parse the module-info file.
>>> b+148
>>> killed this strategy for a while, but it is fixed again. If only I could
>>> have point to target/classes ... ;) Anyway, this is solved once the
>>> structure of the module-info file is final.
>> i've decided to not use -Xmodule to run the test but to merge the
>> of the test and the of the main,
>> this allows me to be able to specify test only dependencies like junit
>> in the of the test.
> For now I've decided not to support module-info files for tests. It is
> very unlikely that it will become a dependency for other projects. So
> it'll only be used within the build lifecycle, and since the user has
> already specified the dependencies, I see no reason why one should add the
> module-info as well. If a dependency is missing, the build will fail.
> Adding module-info here feels paranoid.

I think it's because i think in term of module-info first and not in term of POM file first :)

>>> To prevent users to add their requirements to the module-info file AND
>>> specify which jars belong on which path in either the <dependency> or
>>> the
>>> <configuration> of the maven-compiler-plugin, I think we should "simply"
>>> read the*, gather all requirements and find the
>>> matching
>>> jar. And do that recursively.
>>> * I maintain QDox, a Java source parser, as well.
>> This is exactly what i'm doing [1] but i use javac instead of writing my
>> own parser :)
>> (the fact that i can requires the module java.compiler makes the things
>> easy)
>>>> And also do not forget that deciding to put every jars in the
>>>> modulepath
>>>> do not work because of split packages.
>>> Exactly!
>> [...]
>> Rémi
>> [1]
> >


More information about the jpms-spec-observers mailing list