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.
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. 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. —Dan
