> On May 5, 2016, at 6:10 AM, Alan Bateman <[email protected]> wrote:
>
> In resolveClass then "is class loader corresponding to the closest .." should
> probably be "is the class loader ...". You didn't introduce this of course,
> just noticed it while reading the complete paragraph.
>
> The rest looks okay to me, no objection to Chris's suggestion to re-word
> resolveProxyClass.
I was wondering why the resolveClass and resolveProxyClass methods are
specified differently w.r.t. class loader search. I made only localized change
as I didn’t have the history.
I’m happy to clean up the spec. I’d also fix the spec “user-defined class
loader” which isn’t correct as it also includes built-in app class loader.
* where <code>loader</code> is determined as follows: if there is a
* method on the current thread's stack whose declaring class is not a
* <a href="../lang/ClassLoader.html#builtinLoaders">
* <em>platform class</em></a> (and was not a generated to implement
* reflective invocations), then <code>loader</code> is the class loader
* of such class; otherwise, <code>loader</code> is the {@linkplain
* ClassLoader#getPlatformClassLoader() platform class loader}.
Revised webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.01/
Mandy
