On 4 May 2016, at 20:29, Mandy Chung <mandy.ch...@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.
