On 4/23/2013 11:58 PM, Peter Levart wrote:
The isAssignableFrom check should be correct for well-behaved class
loaders [1]. 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
behavior :)
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.
Mandy
