module-info hygiene

[Robert Scholte]

Hi,

with the introduction of the module-info something interesting is  
happening. Up until now the scope of a Java project was limited to the  
compilation of the classes. In case of Maven the end-user was in full  
control regarding the classpath and the order of entries. With the order  
of the dependencies you can control the order of classpath entries. You  
could add your own dependencies but could also exclude them. The exclude  
is especially powerful in those cases where library builders have made  
mistakes (e.g. junit without test-scope) or simply forgot to remove  
dependencies when refactoring code.
The first project poms are often quite clean, but it requires discipline  
to keep cleaning up your pom, e.g. removing unused dependencies. However,  
you're not really punished if you don't do this.

With the shift to module-info, suddenly every library-builder gets  
control. If the module-info of that library "requires A.B", it means that  
every project using this library MUST have A.B on its module-path. As  
end-user you cannot exclude A.B, nor can you say "B.A replaces A.B for  
x.y.z" in case of duplicate classes as allowed on the classpath. In short:  
the end-users must rely on the discipline of library builders.

This loss of control for the end-user will have huge impact. Maven has a  
analyze-goal in the maven-dependency-plugin which show both unused  
declared dependencies and used undeclared dependencies (which means pulled  
in as transitive dependency, even though the code directly uses it).  
Almost every time I run this goal on any project it detects dependencies  
in one of both groups.

To enforce the discipline, the java compiler should IMHO at least check if  
all required modules are indeed required and if the transitive required  
modules are indeed transitive. The role of the module-info is way too  
important to simply allow all content. The scope is not just about the  
classes anymore; the complete module tree is now locked into the jar. Any  
mis-configured module-info down the tree can never be fixed by the  
end-user, which could block the end-user to use the modulepath.

just sharing my concerns,
Robert