|
From: | Bryce McKinlay |
Subject: | Re: Method.equals() |
Date: | Wed, 20 Feb 2002 11:47:28 +1300 |
User-agent: | 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 default implementation.
regards Bryce.
[Prev in Thread] | Current Thread | [Next in Thread] |