JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible
jan.lahoda at oracle.com
Tue Jun 14 12:29:06 UTC 2016
On 14.6.2016 12:57, Alan Bateman wrote:
> On 13/06/2016 17:12, Jan Lahoda wrote:
>> There is:
>> 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:
> 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
> 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:
> 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.
> 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.
More information about the compiler-dev