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
