classpath
[Top][All Lists]
Advanced

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

Re: Method.equals() question


From: Brian Jones
Subject: Re: Method.equals() question
Date: 07 Apr 2003 23:29:50 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Mark Wielaard <address@hidden> writes:

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

Hmm, so the patch is relatively sane and just needs this splitting
bit?  What parts would be in VMSomethingClass?

Brian
-- 
Brian Jones <address@hidden>




reply via email to

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