Proxy.isProxyClass scalability (original) (raw)

Mandy Chung 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 [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

More information about the core-libs-dev mailing list