Re: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-12-06 Thread Mandy Chung
> On Dec 6, 2016, at 6:17 AM, Chris Hegarty wrote: > > http://cr.openjdk.java.net/~chegar/8169653.01/ Looks good. Mandy

Re: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-12-06 Thread Daniel Fuchs
On 06/12/16 14:17, Chris Hegarty wrote: On 6 Dec 2016, at 13:00, Daniel Fuchs wrote: Hi Chris, Looks good. I wonder about the two different links for platform class loader now. ... You’re right. Since getPlatformClassLoader has a link to the built-in loader verbiage, how about we just drop

Re: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-12-06 Thread Chris Hegarty
> On 6 Dec 2016, at 13:00, Daniel Fuchs wrote: > > Hi Chris, > > Looks good. I wonder about the two different links for > platform class loader now. > ... You’re right. Since getPlatformClassLoader has a link to the built-in loader verbiage, how about we just drop the direct link? Developers

Re: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-12-06 Thread Daniel Fuchs
Hi Chris, Looks good. I wonder about the two different links for platform class loader now. Should the first one perhaps include "nor its ancestor" in the link text? best regards, -- daniel On 06/12/16 12:25, Chris Hegarty wrote: On 6 Dec 2016, at 11:53, Daniel Fuchs wrote: Hi Chris, I

Re: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-12-06 Thread Chris Hegarty
> On 6 Dec 2016, at 11:53, Daniel Fuchs wrote: > > Hi Chris, > > I have an additional suggestion: could you update the > comment of the private ObjectInputStream::latestUserDefinedLoader() > in the same file to align with what the method is actually > doing? > > I looked at what jdk.internal.m

Re: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-12-06 Thread Daniel Fuchs
Hi Chris, I have an additional suggestion: could you update the comment of the private ObjectInputStream::latestUserDefinedLoader() in the same file to align with what the method is actually doing? I looked at what jdk.internal.misc.VM.latestUserDefinedLoader() does, and the comment in ObjectInp

Re: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-12-06 Thread Chris Hegarty
> On 6 Dec 2016, at 11:35, Daniel Fuchs wrote: > > Hi Chris, > > Is that a typo? I see it at two places: > > otherwise, > + * loaded is the {@linkplain ClassLoader#getPlatformClassLoader() > * platform class loader}. > > ("loaded" vs "loader") It is a typo, thanks. For completeness

Re: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-12-06 Thread Daniel Fuchs
Hi Chris, Is that a typo? I see it at two places: otherwise, + * loaded is the {@linkplain ClassLoader#getPlatformClassLoader() * platform class loader}. ("loaded" vs "loader") best regards, -- daniel On 06/12/16 11:27, Chris Hegarty wrote: Mandy and I exchanged some mails off

Re: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-12-06 Thread Chris Hegarty
Mandy and I exchanged some mails off line, here is updated proposed wording. > On 21 Nov 2016, at 09:41, Chris Hegarty wrote: > > JDK-8155977 updated ObjectInputStream::resolveClass, and > resolveProxyClass, to work with the platform class loader, but > inadvertently removed the text describing

RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

2016-11-21 Thread Chris Hegarty
JDK-8155977 updated ObjectInputStream::resolveClass, and resolveProxyClass, to work with the platform class loader, but inadvertently removed the text describing the order in which the call stack is searched, for the 'loader'. The omission, from Java SE 8, is " ... closest such method to the curr