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

[Jan Lahoda]

Hi,

I've updated the patches, reflecting the feedback so far.

The langtools change is now split into two parts, one is only adding the 
new lint key (but no checks are actually performed):
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase1/

And the second part is adding the checks:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase2/

We could push the first part first, and the second one together with 
other changes later, so that the repositories don't have to be updated 
in a lockstep.

In addition to the langtools changes, only the top-level repository 
needs to be changed now, to disable the checks in some modules:
http://cr.openjdk.java.net/~jlahoda/8153362/top-level.01/

Any feedback is welcome!

Thanks,
     Jan

On 14.6.2016 14:29, Jan Lahoda wrote:
> 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.