On Oct 30, 2017, at 6:45 PM, David Holmes wrote:
>
> Hi John,
>
> On 26/10/2017 2:03 PM, John Rose wrote:
>> On Oct 25, 2017, at 8:54 PM, David Holmes wrote:
>>> Though I still feel uncomfortable lying about the nest-host. I don't see
>>> what usecases would be served by doing that. Other than informational uses,
>>> I can't see a reason to actually identify the nest-host which would not be
>>> impacted by lying about that identity. The only truly useful query is for
>>> nestmate access and that doesn't need to expose the identity of the
>>> nest-host and conservatively rejects access if anything goes wrong.
>> I'm sympathetic to this, but that implies that getNestHost should return null
>> rather than this for a non-nesty class. I think it's more valuable that
>> getNestHost
>> return 'this' for non-nesty classes, and therefore also for broken-nest
>> classes.
>
> Ok. The JVMS is proposed to state:
>
> "A class or interface without a NestHost attribute belongs to the nest hosted
> by itself."
>
> That covers top-level classes and all types compiled with an earlier version
> of javac. If we consider a class with an unresolvable, or otherwise invalid,
> NestHost attribute, as-if it had no NestHost attribute, then returning "this"
> is the natural response for that case.
Excellent.
>
>>> Bottom line for my personal preferences:
>>>
>>> - hasNestMateAccess: never throws, always returns true or false
>> Yes!
>
> Okay.
>
>>> - getNestHost(): throw if the host isn't there or else a membership
>>> validation check fails
>> See above.
>
> getNestHost() won't throw, as above.
>
> Suggestion: also add getValidatedNestHost() that can throw?
It's a lot of API for a corner case that doesn't matter much.
Counter-suggestion: void validateNesting() which has no effect
if the class validates properly w.r.t. nesting requirements, and
throws ICCE otherwise. If you want to validate the whole nest
you iterate over getNestMembers. OTOH, if we make getNestMs
validate all that stuff up front then we don't need validateNesting.
So, how about make getNestMs enforce complete bi-di referential
integrity and throw ICCE if that fails. That give a "hook" for forcing
validation.
>
>>> - getNestMembers(): throw if any nest member isn't there or a membership
>>> validation check fails
>> As I said before, I don't mind this choice. Especially if we have
>> hasNestMateAccess.
>
> Okay. getNestMembers() will throw.
Good; see above also.
>
> Now the question is what to throw? Dan's spec change for the access checking
> allows resolution/linkage errors (and VME) to pass through, and specifies
> IllegalAccessError for an invalid nest membership claim. The IAE makes sense
> in the context of an access check - though could also be ICCE.
>
> But in the context of the reflection API, getNestMembers or
> getValidatedNestHost, IllegalAccessError doesn't really make sense - we're
> not trying to access anything. ICCE seems more fitting there.
ICCE stands for "somebody broke the classfiles, either intentionally or not".
That's why I think it is a good result from invalid classfile data, including
the present case, which is invalid nestmate relations. You can only "see"
the full story if someone is asking for the whole nest, but that's exactly
what getNestMs does.
— John
