jdeps -check: add section on exports

[Anthony Vanelverdinghe]

For the record: I've filed this as JI-9034435

Anthony

On 25/03/2016 21:08, Anthony Vanelverdinghe wrote:
> 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
>>>>>
>