[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Method.equals()

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/ 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]