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

[Jan Lahoda]

Hello,

I've updated the patch to the current situation. The top-level 
repository patch is here:
http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/

Langtools repository patch is here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.04-phase2/

Does this look OK?

Thanks,
     Jan

On 17.6.2016 16:18, Jan Lahoda wrote:
> 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.