On 19/12/2017 9:01 AM, Dan Smith wrote:
On Dec 18, 2017, at 3:03 PM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> wrote:
On 19/12/2017 7:28 AM, Dan Smith wrote:
But letting things "show through" is, I think, never what the end
user will want. They will believe that anything in the array returned
by 'getNestMembers' actually *is* a member of the nest.
Given we're only talking about the case where the nesthost is
explicitly listed in NestMembers, or where there are duplicate
(correct) entries in NestMembers, then everything in the returned
array _is_ a member of the nest. The issue is whether we need to
condense the array so that it holds the set of members.
Yeah, I guess I'm mostly just concerned about #2/#6—non-nest members
appearing in the attribute.
You said this:
I recall no discussion of #1 and #3. For #2, #4 and #6 - ie any listed
member that is not validated as being a member - we throw exceptions.
* <p>Each listed nest member must be validated by checking its own
* declared {@linkplain #getNestHost() nest host}. Any exceptions that
occur
* as part of this process will be thrown.
* @throws LinkageError if there is any problem loading or validating
* a nest member or its nest host
In practice these will be IncompatibleClassChangeError for #2 and #6,
and NoClassDefFoundError for #4.
Not clear to me that an error will occur in all cases—if I put
java.lang.String in my NestMembers attribute, validating
java.lang.String by calling its getNestHost isn't going to prompt any error.
Right I need to clarify that the validation performed in getNestMembers
is _not_ done by calling Class.getNestHost on it - as that never throws
any exceptions. The validation is done at the VM level. The doc quoted
should not be linked to #getNestHost. I have an open issue to update
getNestMembers to clarify what's been discussed.
I agree that redundant elements are not ideal but tolerable, depending
on engineering considerations.
Okay.
Thanks,
David
—Dan
