Hi Alan,
On 14.6.2016 12:57, Alan Bateman wrote:
On 13/06/2016 17:12, Jan Lahoda wrote:
Hello,
There is:
https://bugs.openjdk.java.net/browse/JDK-8153362
which is about a new warning that should be produced by javac when
exported API refers to types not exported/accessible to the API clients.
I've put my current javac change here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/
Did you have a short list of names for the lint option before deciding
on "unexportedinapi"? If time has already been put into this and this is
I had a few (e.g. "publishingunexported"), but none of them particularly
nice.
the best of a bad bunch then ignore my mail. I bring it up because it
feels more like a "potentiallynotaccessible" or "notaccessible" or
"leaksnotaccessible". For the cases where we have ended up with
I like "leaksnotaccessible". Unless there would be better ideas or
objections, I'd go with that. Thanks for the ideas!
protected fields in public classes but the field type is package-private
then the field is never accessible. For the JSObject.getWindow case then
consumers will need to require java.desktop to use this method.
Related is the description:
javac.opt.Xlint.desc.unexportedinapi=\
Warn about use of types not visible to clients in exported API
Shouldn't get say something about the type potentially not accessible
rather than visible?
Yes, it should. I'll fix that. Thanks for catching that.
Jan
-Alan
PS: You asked about the JVMCI classes in the hotspot repo. While this
might look strange then it is intentional. The "framework" uses the
reflective APIs to export the otherwise internal packages to the JVMCI
implementation when it is located and loaded.
