Olivier Jolly wrote:
I bumped into a major problem with spring and easymock which boiled
down to being a subtle definition of a Proxy. In the case of the
creation of a proxy which defines the same method as Object (which is
non final and public), the method in the interface must be so that
getDeclaringClass is Object.class and not the actual interface.
Just curious.. are you sure this is a Classpath issue and not
a VM issue?
yes, as far as the VM isn't handling natively the creation of
java.lang.reflect.Proxy. In the Proxy.java source file of classpath
we're (incorrectly) building the proxy with methods that shouldn't be
there.
What does the failure look like?
Within an InvocationHandler, the method instance which is given as
parameter is not equals to Object.class.getDeclaredMethod("...", ...) if
the interface the proxy is built on redefines one of the "core" Object
methods. Easymock is correctly expecting to catch all "equals" call with
Object.class.getDeclaredMethod("equals", new Class[]
{Object.class}).equals(method) which is not the case without my patch.
Still curious.. :-)
It's not an error for an interface to declare a method that matches
an Object method (such as equals), and then for some bytecode somewhere
to INVOKEINTERFACE that method, even though INVOKEVIRTUAL would "make
more sense". E.g. code somewhere in Eclipse does this.
So isn't this an easymock bug? In such a case, wouldn't easymock fail
to catch a valid equals() invocation?
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
