module-info hygiene

[Alan Bateman]

On 17/10/2016 08:32, Peter Levart wrote:

> :
>
> 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.
The module declaration is intended to be authoritative and so we have to 
trust module author when they declare that the module `requires M`. So 
my view is that options such as --exclude-modules that would have the 
effect of dropping requires puts us on the road to anarchy.

That said, I do see Robert's concern that there might be orphaned 
`requires` clauses in some modules.  My module started using the 
preferences API but later the implementation changed to use something 
else. I neglected to remove the `requires java.prefs` from the module 
declaration and the result is that my module cannot compile against or 
run on a run-time image that doesn't include this module. Static 
analysis tools might help here, as might the IDE. We are used to IDEs 
highlighting unused `import` statements and in time then I expect they 
will do the same for apparently unused `requires` clauses in 
module-info.java. If the usage is purely reflective then the module 
author might need to put a comment on the `requires` clause to avoid 
other maintainers from removing it (a bit like "// used by javadoc" in 
comments today when an import is for an unqualified reference in the 
javadoc).

Another part to Robert's mail is the case where something is making use 
of types in modules that it doesn't depend on. Assuming these are static 
references then they will be caught at compile-time. This is big 
improvement compared to today's class path.

A more general comment is that module authors will need to learn a few 
new things about compatibility and refactoring. One example is changing 
`requires transitive M` to `requires M` is an incompatible change.  
Another is splitting a module (several sub-cases) where the module 
author will need to add `requires transitive` to avoid breaking 
consumers. There are lots of opportunities here for authoritative books 
and documentation to help module authors do this right.

-Alan