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

[Peter Levart]

Hi David,

On 11/17/2017 11:44 AM, David Holmes wrote:
> Hi Peter,
>
> On 17/11/2017 7:45 PM, Peter Levart wrote:
>> Hi David,
>>
>> On 11/16/2017 10:52 PM, David Holmes wrote:
>>>>> John prefers to minimize exceptions for the Java API. :)
>>>>
>>>> Suppose that this is basic reflection API to get nestmate 
>>>> information and that it will also be used for reflective access 
>>>> checks. For example in 
>>>> jdk.internal.reflect.Reflection#verifyMemberAccess, which is used 
>>>
>>> It isn't. The reflection API is purely for "external" use. Real 
>>> access checks are performed in the same way as the VM access checks 
>>> - as required - and will report the same exceptions in the same way.
>>>
>>> David 
>>
>> Real access checks performed by bytecode(s), yes. But what about 
>> reflective access checks - those performed by Method.invoke, 
>> Field.[get|set], Constructor.newInstance? They will have to be 
>> revised some day to include the nestmates. What facility should those 
>> methods use to implement the checks (the guts of those checks is in 
>> jdk.internal.reflect.Reflection#verifyMemberAccess).
>
> Yes and the real nestmate access check for use by invoke etc has 
> already been implemented in there.
>
> http://hg.openjdk.java.net/valhalla/valhalla/file/df423aeaa8d1/src/java.base/share/classes/jdk/internal/reflect/Reflection.java 
>

Oh, sorry. I have been looking at wrong repository (jdk master) and 
thought the proposed core reflection nestmate API was the 1st change to 
reflection. I see you have already updated invoke/get/set/newInstance.

>
>> Is the plan to have special internal native methods to facilitate 
>> that? 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?

Regards, Peter

>
> David