Re all,
Mark Wielaard wrote:
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.
First I wanted to implement it with a contains, but unfortunately,
contains relies on equals, which will check that the declaring class are
the same before saying that two methods are equals. In this case, we
know we have the same methods expected that the declaring class are
differents, that's the whole point of the fix, hence this little method
which acts like a contains with a very specific "equals". If we had a
contains(Object, Comparator) on collections, I would have use it.
Please feel free to commit it either as is or by checking
coreMethods.contains(). The logic seems fine to me either way.
Okey, I'll commit later today with this method if nobody comes out with
a better solution by then...
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.
I meant mauve is already a monster with KEYS=classpath :)
Cheers,
Take care
Mark
Olivier
