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

[David Holmes]

Hi Peter,

On 20/11/2017 4:31 PM, Peter Levart wrote:
> 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?

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

> 
> Regards, Peter
> 
>>
>> David
>