Hi Olivier, On Sun, 2006-02-19 at 22:43 +0100, 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.
O. Good catch again! > I just submitted a mauve testlet to stress this point and here is the > proposition of fix in Proxy.java (for non native Proxy implementations, > that's it). When iterating over the methods to be added to the proxy, if > any is matching an Object one (by its name and parameter types only), it > is skipped. Since we're already adding them automatically, it is not > missing of the resulting proxy and the declaring class remains Object.class > > 2006-02-19 Olivier Jolly <olivier.jolly> > > * java/lang/reflect/Proxy.java > (ProxyData.getProxyData): Skipped overriding of core methods. > (ProxyData.isCoreObjectMethod): New method. Instead of adding a new method, could you just check ProxySignature.coreMethods.contains(sig)? Not that it matters a lot since I don't think the set in ProxySignature.coreMethods and what is checked in ProxyData.isCoreObjectMethod() will ever get out of sync. Please feel free to commit it either as is or by checking coreMethods.contains(). The logic seems fine to me either way. > I have not yet passed the integrality of mauve tests to ensure > regression, but I will by the time this patch is accepted :) Yeah. Mauve is getting a bit big. You can run a subset by defining KEYS (see the README). The autobuilder on builder.classpath.org will run all tests. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
