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

[Chris Hegarty]

On 4 May 2016, at 20:29, Mandy Chung <mandy.chung at oracle.com> wrote:

> The default implementation of ObjectInputStream::resolveClass and resolveProxyClass finds the user-defined class loader on the stack and assumes that only system classes are loaded by null loader. As JDK modules are deprivileged, classes on the stack defined by the platform class loader.
> 
> These methods should be updated to prepare if any system class are defined by the platform class loader and its ancestors instead. 
> 
> As for the implementation, I fix JVM_LatestUserDefinedLoader to returns the first non-null class loader on the stack that is not platform class loader.   This is so fragile and would be really nice if this  could go away while the past work shows that it’s unlikely - Alan may say more on this.  If this stays, I’d like this to be replaced with StackWalker API and remove such built-in logic in the VM in the future.

That would be a good future enhancement.

> Webrev:
>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155977/webrev.00/

The changes look good to me.

The wording for resolveProxyClass seems a little overly complicated,
and always has been. Would it be better to just take the same, more
direct, wording as resolveClass?

  where loader is determined as follows: if there is a
  method on the current thread's stack whose declaring class was
  defined by a user-defined class loader (and was not a generated to
  implement reflective invocations), then loader is class
  loader corresponding to the closest such method to the currently
  executing frame; otherwise, loader is the {@linkplain
  ClassLoader#getPlatformClassLoader() platform class loader}. 

-Chris.