mandy.chung at oracle.com
Wed Apr 24 22:01:16 UTC 2013
On 4/23/2013 11:58 PM, Peter Levart wrote:
>> The isAssignableFrom check should be correct for well-behaved class
>> loaders . However, for non well-behaved class loaders, I'm not
>> absolutely confident that this is right. The case that I was
>> concerned is when intf.isAssignableFrom(proxyClass) returns true but
>> the proxy class doesn't implement the runtime types (i.e. given
>> interfaces). Precise check should be to validate if the given
>> interfaces == the proxy interfaces implemented by the cached proxy
>> class (i.e. proxyClass.getInterfaces()).
> Really? This can happen? Could you describe a situation when?
> Are you thinking of a situation like:
> - intf1: pkg.Interface, loaded by classloader1
> - intf2: pkg.SubInterface extends pkg.Interface, loaded by classloader1
> - intf3: pkg.Interface extends pkg.SubInterface, loaded by
> classloader2 which is child of classloader1
Similar but classloader2 is non well-behaved classloader e.g. doesn't
have relationship with classloader1; otherwise I don't think it's
possible to define intf3 (classloader1.loadClass("pkg.Interface") should
be resolved with intf1 instead (not its own defined pkg.Interface).
I haven't been able to identify such a case but I wasn't able to prove
it not possible either as it is subject to non well-behaved class loader
The isAssignableFrom method returns true not only if it's identical but
also if it's a superinterface that a class implements.
> Now you call:
> proxy3 = Proxy.getProxyClass(classloader2, intf3);
> followed by:
> proxy1 = Proxy.getProxyClass(classloader2, intf1);
> Is it possible that the second call succeeds and returns proxy1 ==
> proxy3 ?
If it's possible to have intf1 and intf3 different runtime type of the
same name, the second getProxyclass call would return proxy3 since
intf1.isAssignableFrom(proxy3).What I'm not certain is - how would
classloader2 be able to define intf3 with classloader1 defining intf1?
We can't really predict how a non well-behaved class loader and thus I
wouldn't exclude the possibility.
It seems that the key matching the list of interface names should
already be a safe guard but we would need a proof for a name +
isAssignableFrom is equivalent to that runtime type to determine its
correctness with the consideration of all possible class loader
behaviors that I don't have. That's what my feedback was about.
More information about the core-libs-dev