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

David Holmes david.holmes at oracle.com
Tue Feb 13 04:04:12 UTC 2018

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.

>>>>>> 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.

More information about the valhalla-spec-observers mailing list