[Top][All Lists]
[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>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Method.equals() question,
Brian Jones <=