module-info hygiene

[Robert Scholte]

On Mon, 17 Oct 2016 12:59:25 +0200, Alan Bateman <Alan.Bateman at oracle.com>  
wrote:

> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at maven.apache.org
> For additional commands, e-mail: dev-help at maven.apache.org
>

I understand why *in concept* the --exclude-modules is an unwanted option.  
The module-info clearly states "requires A.B", otherwise it should have  
been marked as "optional" or simply removed.
Now that the user fully relies on the discipline of the library-builders:  
users cannot control the modules, nor will the compilation fail in case of  
an incorrect module-info.
It is really a matter of hoping that library-builders are aware of this  
and maybe it will make libraries more popular based on the quality of the  
module-info instead of the quality of the classes. As a user you probably  
don't want to be forced to choose on these facts.
And for the smaller and medium application this will work, but for the  
larger this can really become problematic.

Up until now the compiler was always about "is everything on the classpath  
to compile the classes?". If there is more, we'll, it'll be ignored.  
"More" was never a problem. And if it was a problem, the user could fix it.

Now we have the module-info, and it is actually a safety-belt for the  
library-builder! Now he can never be blamed (almost): the module-info  
contains at least all info to compile and run this library, maybe even  
more for free.
But with a lot of libraries with their own safety-belts there can be (and  
will be) conflicts and there's nothing you can do right now (apart from  
dropping all safety-belts).
For the end-user all these small safety-belts doesn't feel very "safe". He  
would feel much better if he had some of the control back (and yes, he's  
very well aware of the possible consequences).

The introduction of the module-info comes with great powers, but that  
comes with great responsibilities as well. I would like to see that the  
compiler could help with controlling those required modules (which would  
mean that "More" is considered to be a problem). Static analysis is IMHO  
just a hint, ignorable, but to me it shouldn't be that way.

Robert