module-info hygiene

[Peter Levart]

Hi Robert,


On 10/16/2016 08:52 PM, Robert Scholte wrote:
> 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

I think this is a real concern.

Do we need an --exclude-modules (in addition to --add-modules) option on 
javac, java and jlink commands?

--exclude-modules would be different to --limit-modules. If some module 
requires module M and there is no module M on the module path or it is 
not observable because it was not mentioned in the --limit-modules 
option, then an exception is raised. OTOH if some module X requires 
module M and module M is mentioned in the --exclude-modules option, then 
such requires is silently ignored in hope that module X will not 
actually need types from module M.

Would that satisfy your concerns?

Regards, Peter