module-info hygiene

[Ioi Lam]

On 10/17/16 12:43 PM, Robert Scholte wrote:
> 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
>>
>>
>
> 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.
>

Maybe a "javac -Xlint:unusedmodules" can give warnings that hopefully 
most library developers will notice?

Or, for some reason if the library uses module X only via reflection, 
perhaps there can be a way to turn off the warning for just module X?

Another option is to have a static analysis tool (similar to jdep) that 
can print out all the dependencies and give various warnings/suggestions 
regarding minimizing the "requires" clauses?