JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

Jan Lahoda jan.lahoda at oracle.com
Tue Jun 14 12:29:06 UTC 2016

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 

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


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

More information about the compiler-dev mailing list