Review Request JDK-8155977: Update ObjectInputStream::resolveClass and resolveProxyClass to work with platform class loader

[Mandy Chung]

> On May 5, 2016, at 6:10 AM, Alan Bateman <alan.bateman at oracle.com> 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