jdeps -check: add section on exports

[Anthony Vanelverdinghe]

Hi Rémi

Yes, I admit I didn't give that too much thought, just wanted to mention 
the analog with parameter types ;) I was thinking something like 
SerializableFileSystem, where a client could deduce a subclass from the 
type name (similar to CustomList, where it's reasonable to assume it's a 
List implementation).

Kind regards, Anthony

On 24/03/2016 20:53, forax at univ-mlv.fr wrote:
> Hi Anthony,
>
> ----- Mail original -----
>> De: "Anthony Vanelverdinghe" <anthony.vanelverdinghe at gmail.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: jigsaw-dev at openjdk.java.net
>> Envoyé: Jeudi 24 Mars 2016 20:37:23
>> Objet: Re: jdeps -check: add section on exports
>>
>> 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.
> C# currently emit an error if you try to use a non visible type in the signature, and it doesn't seem to cause too much trouble to its users.
> That said you are right that when the compiler emits an error, it should also indicates that using a supertype is perhaps a good option.
>
>> 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).
> If the client doesn't see the super-type, how can it knows that 'subclass' is a subclass of that super-type ?
> Apart sending null, it don't think you can do better.
>
>>   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
> regards,
> Rémi
>
>> 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
>>>>
>>