jdeps -check: add section on exports

[Anthony Vanelverdinghe]

What's the next step? Will someone with JIRA access file a javac 
enhancement for this, or shall I do so myself through bugs.java.com? 
(I'm not sure what the preferred option is for issues that have already 
been discussed on the mailing list)

Thanks,
Anthony

On 24/03/2016 20:56, Alex Buckley wrote:
> 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
>>>>