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, fo...@univ-mlv.fr wrote:
Hi Anthony,
----- Mail original -----
De: "Anthony Vanelverdinghe" <anthony.vanelverdin...@gmail.com>
À: "Remi Forax" <fo...@univ-mlv.fr>
Cc: jigsaw-dev@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.vanelverdin...@gmail.com>
À: jigsaw-dev@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
