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

Paul Sandoz paul.sandoz at oracle.com
Tue Feb 13 01:45:18 UTC 2018

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

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


More information about the valhalla-spec-observers mailing list