On 13/02/2018 11:45 AM, Paul Sandoz wrote:
On Feb 12, 2018, at 1:55 PM, David Holmes <david.hol...@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". ;-)


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 I, for one, prefer a "user pays" scheme over an "everyone pays" scheme (which is what disallowing duplicates would also be).

David

Paul.

Reply via email to