[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 20 Feb 2002 11:47:28 +1300
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
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
- Method.equals(), Mark Wielaard, 2002/02/19
- Re: Method.equals(),
Bryce McKinlay <=