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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
