Re: Method.equals()

[Bryce McKinlay]

Mark Wielaard wrote:

> I am going through the patches that the Orp developers submitted to
> Classpath. The following patch to Method puzzles me:
>
> 2001-12-17  Wu Gansha <address@hidden>
>
>        * vm/reference/java/lang/reflect/Method.java: Reimplemented
> equals(), refined toString().
>
>
> Why/When is this neccessary? The comment to equals says:
>
> Two Methods are semantically equivalent if they have the same declaring
> class, name, and parameter list.  This ignores different exception
> clauses, but since you can't create a Method except through the VM,
> this is just the == relation.
>
> So this comment is wrong for Orp, but when does this happen?

This comment is also wrong for GCJ, where a new Method object is always 
created by a getMethod call, since Method is really just a wrapper 
around an internal reflection data structure. Some VMs may use the 
Method class as their native/internal representation, and in that case 
using == would be an optimization.

> Maybe we should just mark this method "native" in Classpath and
> leave it to the VM implementor.

I don't think it is neccessary to make it native. Method is already part 
of the VM interface, so VMs can modify it or make it native as they 
wish. I think the more conservative approach should be taken by the 
default implementation.

regards

Bryce.