jdeps -check: add section on exports

[forax at univ-mlv.fr]

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