On 05/05/2016 17:59, Mandy Chung wrote:
:
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/
This looks okay to me. I noticed the existing spec also methods "class
loaders of generated reflection implementation classes" and not clear
that this should be in the normative text. Anyway, not your doing and
I'm suggesting we change it now.
-Alan.
