[Nestmates] Draft core reflection API
david.holmes at oracle.com
Wed Nov 8 00:19:03 UTC 2017
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".
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.
More information about the valhalla-spec-observers