[JIGSAW] Automodules and their context

[Robert Scholte <rf...@apache.org>]

The opinions regarding automodules has creates 2 groups: those who want to  
support it and those who don't.

But let's start with explaining the concept of automodules. It is  
introduced for ease of transition to Java9/Jigsaw. If you add a  
module-info.java to you project, you have to sum up *every* module  
required by this project.
I wasn't aware of the 'every', which is an important detail for this  
discussion.

The most used example looks like this:

module myapp {
     requires mylib;             // a named module, assume part of Maven  
multimodule project
     requires java.base;         // a named module, part of Java
     requires java.sql;          // a named module, part of Java
     requires jackson.core;      // an unnamed module, name extract from  
filename (jackson-core-2.6.2.jar)
     requires jackson.databind;  // an unnamed module, name extract from  
filename (jackson-databind-2.6.2.jar)
}

So even if you have all jars on either classpath or modulepath and you  
remove both jackson automodules (an unnamed module on the modulepath,  
which name is calculated based on the filename) as requirement from this  
file, the code won't compile ('error: cannot find package  
com.fasterxml.jackson.databind' ).
There is one trick to make it work, add the following commandline  
argument: --add-reads myapp=ALL-UNNAMED (you have to do this for every  
module if they depend on classpath libraries).

The discussion is all about reliability and whether automodules are  
reliable.

As long as myapp is the final product and will *never* become a dependency  
for any other project, then automodules seem fine. Without additional  
arguments you can ensure that all expected jars are available at both  
compiletime and runtime. If fasterxml thinks that jackson.core and  
jackson.databind are not appropriate module names and change it, as  
developer of myapp it is easy to adjust module-info and release a new  
version of myapp.

The issues with automodules start when your project will become a  
dependency for other and you cannot predict if there will be conflicts.
There are a couple of conflicts possible:
- dependencies with the same artifactId but different groupIds ( e.g there  
are over 300 'library' artifactIds with different groupIds. You cannot  
uniquely identify them in the module-info file. These are all forced to  
pick a dfferent moduleName, which will then break with the original  
moduleName).
- if different modules are using the same package, you cannot use those  
modules together.

As long as we cannot ensure how a jar will be used (as dependency or as  
distribution), we are IMHO enforced to pick the most reliable option for  
both systems, i.e. don't allow unnamed modules in the module-info file.

The result would be

module myapp {
     requires mylib;             // a named module, assume part of Maven  
multimodule project
     requires java.base;         // a named module, part of Java
     requires java.sql;          // a named module, part of Java
//    requires jackson.core;
//    requires jackson.databind;
}

This means that the compiler will add the following commandline arguments  
--add-reads myapp=ALL-UNNAMED --add-reads mylib=ALL-UNNAMED
I've been experimenting with this, and it works for first level modules.  
For all other modules in the graph I need the next version from ASM to be  
able to extract the modulename from the module.info.class

If jars like this end up in Central or any other artifact repository, it  
means that all other tools also need to use the --add-reads  
<MODULE>=ALL-UNNAMED trick.
Is this acceptable?

If not, then the worst case scenario seems to be: build the module-info up  
 from the bottom. Don't allow module-info files if there's a reference to  
an unnamed module.
Allowing to specify just a subset of the requirements comes with the extra  
arguments price, I'm not sure if that's worth it.

WDYT?

Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org