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 <[email protected]> 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
