[Nestmates] Add a core reflection API to get nestmate information

[Peter Levart]

Hi David,

On 11/20/2017 07:36 AM, David Holmes wrote:
>>>> I don't quite understand why should a Class.isNestmateOf(Class) 
>>>> behave any differently than real VM access check.
>>>
>>> Purely because of the difference in exception handling. The view was 
>>> that the reflection API should mostly "absorb" exceptions.
>>
>> Absorbing exceptions is generally a bad idea. In this particular 
>> case, you are trying to hide an implementation detail and instead lie 
>> to the user about the nest membership. Some information is lost on 
>> the way and that's not helping the user at all. Not being in the same 
>> nest and not being able to evaluate the answer are two different 
>> things and as much as someone might think the user shouldn't care, 
>> the need to discriminate them is probably going to arise and users 
>> will have to do sub-optimal things to accomplish that. Why not give 
>> them the precise tool to start with?
>
> That was my personal initial position too. But the EG discussions went 
> elsewhere:
>
> http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-October/000386.html 
>
>
> Cheers,
> David 

Your comment in the issue:

https://bugs.openjdk.java.net/browse/JDK-8187768?focusedCommentId=14123862&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14123862

...describes how access checking for private members behaves in VM and 
what are the outcomes when class attributes are missing or not 
consistent (access is denied - IllegalAccessError is thrown) vs. when 
nest-host class can not be resolved (NoClassDefFoundError is thrown). I 
think this is sound.

In reflective API, it is common practice for IllegalAccessException to 
be thrown where VM would throw IllegalAccessError, but 
NoClassDefFoundError is thrown as is when various reflective methods are 
invoked. For example, Class.getDeclaredField(fieldName) throws 
NoClassDefFoundError when the field's type can not be resolved. Likewise 
for method's and constructor's parameter types. Class.getDeclaredField() 
is not trying to hide the return type resolution error by lying about 
the existence of the field and throwing NoSuchFieldException instead. So 
why should Class.isNestmateOf(Class) hide the NoClassDefFoundError and 
lie about nest membership instead?

I agree that Class.getNestMembers() is a special case, but I think it 
should nevertheless propagate NoClassDefFoundError when nest-host can 
not be resolved, while resolution errors for other nest-members listed 
in nest-host could just skip them from the result (to allow for 
optimized jars). Although maybe, jar optimizers should rather "patch" 
the nest-host attribute and remove members that are not included. They 
would have to be aware of nestmate attributes to not accidentally remove 
the nest-host class from the optimized jar anyway, or rearrange 
attributes to designate one of remaining classes to be new nest-host in 
optimized jar.

Regards, Peter