Re: Method.equals() question

[Mark Wielaard]

Hi,

On Mon, 2003-03-03 at 19:45, Archie Cobbs wrote:
> So, let me try to summarize this thread (to confirm my own understanding).
> 
> #1 Because Method, Field, and Constructor are mutable objects, every
>     method that returns a Method, Field, or Constructor object should
>     instantiate a new one object instead of caching and reusing them.
>     Therefore, implementing equals() by comparing object references
>     is incorrect.

Yes. It is probably best to write some Mauve tests to check that the
accesibility of two Method/Field/Constructor objects don't interfere
with each other, but that it does keep the "equals()".

> #2 The definition of equals() uses the phrase "same declaring class".
>     The term "class" is taken to mean the pair <classname, ClassLoader>.
>     I.e. two classes are not the "same" if they have been loaded by
>     different class loaders.
>
> #3 Using this same definition, two classes are "the same" iff they have
>     the same Class object (obj1 == obj2). As a corollary, two classes
>     loaded by different Class loaders have different Class instances.

Yes.

> The practical upshot of this is that the equals() methods that currently
> exist in Classpath for Field and Constructor need to be fixed. But the
> fixes could use "obj1.getDeclaringClass() == obj2.getDeclaringClass()"
> as part of the test.
> 
> Method also needs to be fixed, but for a different reason (it doesn't
> compare the return types as it should (referring to Classpath 0.05)).

Yes, thanks for the bug report btw. That one is nasty because you cannot
define such method in the language java (but you can in byte code).

While we are fixing all this I would split all these classes into a
public SomethingClass (that should be moved out vm/reference) and a
package private (final) VMSomethingClass (that should be moved in to
vm/reference).

Cheers,

Mark