Final nestmates spec
Dan Smith
daniel.smith at oracle.com
Mon Dec 18 23:01:11 UTC 2017
> On Dec 18, 2017, at 3:03 PM, David Holmes <david.holmes at 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.
I agree that redundant elements are not ideal but tolerable, depending on engineering considerations.
—Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20171218/f1858676/attachment.html>
More information about the valhalla-spec-experts
mailing list