Proxy.isProxyClass scalability

[Mandy Chung]

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