Advice + proposals regarding automodule naming

[Robert Scholte]

On Thu, 19 Jan 2017 23:47:11 +0100, <forax at univ-mlv.fr> wrote:

> ----- Mail original -----
>> De: "Robert Scholte" <rfscholte at apache.org>
>> À: forax at univ-mlv.fr
>> Cc: jpms-spec-experts at openjdk.java.net, "Brian Fox"  
>> <brianf at sonatype.com>
>> Envoyé: Jeudi 19 Janvier 2017 21:07:51
>> Objet: Re: Advice + proposals regarding automodule naming
>
>
> [...]
>
>>>
>>> The real problem is that you can have jars in the classpath and in the
>>> module path, and it doesn't mean the same thing.
>> Exactly!
>>
>>> Build tool do not have to manage automatic modules, you have to manage
>>> automatic modules only if you introduce a rule that decide where to put
>>> each jar.
>>
>> That rule is already there, it is the "require M.N" in the module-info
>> file, but it isn't aware if that module automatic or not. This file  
>> should
>> be the only place where people should care about Jigsaw related
>> definitions.
>
> clever :)
>
> So you start with the current code, check if there is a  
> module-info.java, if so all required modules need to be in the  
> modulepath recursively, everything else is in the classpath.
>
>> At conferences THE returning question is: can you generate
>> the module-info for me, because I've already specified my dependencies  
>> in
>> the pom. So there is already some frustration here, so we most be very
>> clear what belongs where and what every responsibility is:
>> pom.xml : specify the dependency coordinates you want to use, so Maven  
>> can
>> download them and can make them available for the maven-plugins
>> module-info.java : specify the modules required to compile and/or run;
>> these will be checked upfront to confirm everything is there.
>> maven-compiler-plugin : build up the correct arguments to call the java
>> compiler.
>
> I agree,
> you also need to crosscheck that the rules in the pom.xml match the  
> rules in the module-info.java (or the other way around).
>
>>
>> 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.

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.

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.

>> 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  
> module-info.java of the test and the module-info.java of the main,
> this allows me to be able to specify test only dependencies like junit  
> in the module-info.java 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.

>>
>> 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 module-info.java*, 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]  
> https://github.com/forax/pro/blob/master/src/main/java/com.github.forax.pro.helper/com/github/forax/pro/helper/parser/JavacModuleParser.java