Final nestmates spec

Dan Smith daniel.smith at
Mon Dec 18 23:01:11 UTC 2017

> On Dec 18, 2017, at 3:03 PM, David Holmes <david.holmes at> 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.

I agree that redundant elements are not ideal but tolerable, depending on engineering considerations.


More information about the valhalla-spec-observers mailing list