Advice + proposals regarding automodule naming

[Robert Scholte]

On Sat, 21 Jan 2017 11:07:12 +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é: 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;
>
> @MavenDependency("guava=com.google.guava:guava")
> 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
>
> @SuppressWarnings("maven-dependency:guava=com.google.guava:guava")
> 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.
>

This is an interesting suggestion, but is ignoring the case of collisions  
with auto module names.
For example:
module myapp {
   requires dep1;
   requires dep2;
}

dep1 has a dependency on com.foo:library
dep2 has a dependency on com.acme:library

and of course all deps and library jars don't have a module-info.

For Jigsaw it might look like the same 'library', but on the module-path  
both jars are required, that's not allowed because they result in the same  
modulename, right?

I don't think some like this can fix that:
@MavenDependency("dep1:library=com.foo:library","dep2:library=com.acme:library")

Robert

>>
>> 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
>>> 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.
>>
>
> 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 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
>
> Rémi