jdeps -check: add section on exports

[Anthony Vanelverdinghe]

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
>>