jdeps -check: add section on exports

[Alex Buckley]

I think this is very well argued.

Alex

On 3/24/2016 12:37 PM, Anthony Vanelverdinghe wrote:
> I believe an error would be too harsh. Suppose I have a method:
>
> public CustomList<Foo> getFoos() { ... }
>
> with problematic type CustomList. Then there are multiple options to
> resolve this, e.g.:
> - replace CustomList with a super type, likely List/Collection
> - make the method (package-)private
> - move CustomList to an exported package
> - export CustomList's package
>
> I believe that the last option would typically not be the best one
> (assuming the developer has given some thought to which set of packages
> to export & there are relatively few problematic usages). However, if
> javac would treat this as an error, some developers would be annoyed by
> their module not compiling and choose the path of least resistance: add
> a bunch of "exports" clauses to module-info.java in order to make the
> compiler happy (especially if the compiler would propose them to do so).
> If, on the other hand, it were an -Xlint check or warning, those
> developers wouldn't be bothered, and other developers could still use
> -Werror to have them treated as an error instead.
>
> Moreover, I don't think an issue like this should fail the compilation:
> even if the example above would make it into a module: at worst a client
> could treat the result as an accessible super-type & use it (analog, for
> the case where an inaccessible type is used as a parameter, where a
> client could try to pass in an accessible subclass instance). But even
> then: the module could subsequently fix the issue (thereby possibly
> breaking some clients, but I'd say it wasn't very responsible of them to
> use inaccessible types in the first place).
>
> Kind regards,
> Anthony
>
> On 23/03/2016 19:31, Remi Forax wrote:
>> In my opinion, it should be a warning (or even an error) in javac,
>> you should not create a bad module in the first place.
>>
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Anthony Vanelverdinghe" <anthony.vanelverdinghe at gmail.com>
>>> À: jigsaw-dev at openjdk.java.net
>>> Envoyé: Mercredi 23 Mars 2016 19:26:24
>>> Objet: jdeps -check: add section on exports
>>>
>>> Hi
>>>
>>> It would be great if jdeps -check would also have a section on exports:
>>> this section would list non-exported packages which contain types that
>>> are exposed (e.g. through method signatures) by exported packages.
>>> Ideally, those appearances should be listed under each package, i.e.:
>>>
>>> com.foo.impl
>>>       type X is exposed by member Y of exported type Z
>>>
>>> Using this, one could easily see whether the package should indeed be
>>> exported, or whether a method was mistakenly made public, or ...
>>>
>>> JDK-8147050 already mentions the similar case of checking whether or not
>>> a "requires" ought to be public.
>>>
>>> What do you think? Should I file an issue for this?
>>>
>>> Kind regards,
>>> Anthony
>>>
>