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.hol...@oracle.com>
wrote:
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". ;-)
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.
