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

[Jan Lahoda]

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.