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

Jan Lahoda jan.lahoda at oracle.com
Tue Sep 27 12:42:08 UTC 2016


Any feedback on the top-level repository changes?



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

More information about the compiler-dev mailing list