API Updates: 8191116: [Nestmates] Update core reflection, MethodHandle and varhandle APIs to allow for nestmate access

[David Holmes]

On 13/02/2018 12:51 PM, David Holmes wrote:
> On 13/02/2018 12:39 PM, Paul Sandoz wrote:
>>> On Feb 12, 2018, at 6:24 PM, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>>
>>> On 13/02/2018 11:45 AM, Paul Sandoz wrote:
>>>>> On Feb 12, 2018, at 1:55 PM, David Holmes <david.holmes at oracle.com> 
>>>>> wrote:
>>>>>> getNestMembers
>>>>>> —
>>>>>> "The list of nest members in the classfile is permitted to contain 
>>>>>> duplicates, or to explicitly include the nest host. It is not 
>>>>>> required that an implementation of this method removes these 
>>>>>> duplicates."
>>>>>> The "or to explicitly include the nest host” suggests it might not 
>>>>>> include the nest host, but a prior statement says it will be 
>>>>>> present in the zeroth element.
>>>>>
>>>>> The "or" pertains to the list of nest members in the classfile - ie 
>>>>> the contents of the NestMembers attribute. The returned array of 
>>>>> nestmembers will always contain the nesthost as the zeroeth 
>>>>> element, but may also contain it somewhere else if the classfile 
>>>>> explicitly listed it in nestmembers.
>>>>>
>>>> I see, it’s easy to misread, well i did :-) Perhaps call out the 
>>>> attribute and provide a link to the JVMS?
>>>
>>> I can add a link to JVMS if that is what we normally do. As for 
>>> misreading ... the subject of the sentence is "The list of nest 
>>> members in the classfile". ;-)
>>>
>>
>> I know :-) most developers will not be thinking at the classfile level 
>> so some link for those that are interested or care is helpful i think.
> 
> Okay will see what I can reasonably add.

Added JVMS ref:

      * <p>The list of nest members in the classfile (JVMS 4.1) is 
permitted to
      * contain duplicates, or to explicitly include the nest host.

David
-----
> 
>>
>>>>>> Why the ambiguity over duplicates? is this motivated by 
>>>>>> performance? this may just push the cost to clients that have to 
>>>>>> always remove duplicates to function reliably and may be cause 
>>>>>> bugs if duplicates are rare and induced by certain relationships 
>>>>>> or loading patterns. My inclination would be for the returned 
>>>>>> array to not contain duplicates.
>>>>>
>>>>> Yes performance. Having to check for duplicates adds a cost to 
>>>>> every single well formed call to this API to account for something 
>>>>> that the specification allows to happen but which we don't expect 
>>>>> to happen and which javac will never produce. This has all been 
>>>>> discussed previously.
>>>>>
>>>> Ok, it’s unfortunate that the cost will be placed on the developer 
>>>> who has to code defensively in case there might be duplicates i.e. 
>>>> the performance cost is pushed to an unbounded set of places (or 
>>>> places where bugs may lurk).
>>>
>>> There's really no expectation that the developer will need to program 
>>> defensively here as we don't expect compilers to produce such 
>>> classfiles.
>>
>> But the developer will not know that since they will be reading the 
>> JavaDoc.
>>
>>
>>> But I, for one, prefer a "user pays" scheme over an "everyone pays" 
>>> scheme (which is what disallowing duplicates would also be).
>>
>> It’s an awkward situation, experience suggests this type of thing 
>> bites back later on, so my inclination is to take the hit in the JDK 
>> and not return dups. The implementation might be able to cache 
>> information on the internal ReflectionData class.
> 
> Please see John's response on this:
> 
> http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-December/000465.html 
> 
> 
> Thanks,
> David
> 
>> Paul.
>>