module-info hygiene

Sun Jun 11 06:44:21 UTC 2017

 Hi!

As far as I can tell, no linter option for unused requires clauses was
introduced. I think it would be very helpful - is it still being
considered?

 so long ... Nicolai

On 18.10.2016 20:20, Ioi Lam wrote:
> 
> 
> 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?
> 

-- 

PGP Key:
    http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
    http://codefx.org
        a blog about software development
    https://www.sitepoint.com/java
        high-quality Java/JVM content
    http://do-foss.de
        Free and Open Source Software for the City of Dortmund

Twitter:
    https://twitter.com/nipafx