[Nestmates] Draft core reflection API

[David Holmes]

Hi Dan,

Thanks for taking a look at this.

On 8/11/2017 9:21 AM, Dan Smith wrote:
> I would be careful to match the behavior of 'isNestmateOf' to JVMS 5.4.4, rather than define it in terms of 'getNestHost'. In particular, 'c.isNestmateOf(c)' shouldn't need to perform any class loading.

I could short-circuit that case, but why special case this instead of 
just retrieving the nest host (which may need to be loaded)? This is not 
an access-check (for which we bail out very early for the same class) 
but a simple query, so the access-check process per JVMS 5.4.4 don't 
directly need to apply.

> For other cases, if class loading errors occur, is the proposal to swallow them and return 'false'? That seems okay, I guess, but is a different conclusion than what we came up with in JVMS.

This was recently discussed on this list under "nestmates spec open issues".

http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-October/000386.html

John prefers to minimize exceptions for the Java API. :)

> The other operations are not directly defined by JVMS and so have more flexibility to decide for themselves what is sensible behavior.
> 
>> On Nov 7, 2017, at 3:31 AM, David Holmes <David.Holmes at oracle.com> wrote:
>>
>> I would prefer it if there were some definitive source we could refer to that explains this rather than putting an ad-hoc definition into the API docs. Perhaps we need something in the JLS (as API docs tend not to reference the JVMS). ??
> 
> I don't think there's any good reason for this. The reflection API deals in class file artifacts, so naturally should sometimes refer to their specification. It also deals in a Java-language-based view of class file artifacts, and in those cases it makes sense to refer to JLS.

Okay so no JLS reference but potentially a JVMS reference, and/or some 
more general class or package javadoc as Brian suggested.

Thanks,
David
-----

> —Dan
>