Re: Method.equals() question

[Archie Cobbs]

Chris Gray wrote:
> > > I'm assuming here that the VM guarantees that only one Method object
> > > will ever be created for each declared method in a class.
> >
> > I used to think that this would be the optimal thing todo for a VM. But
> > in reality each Method object returned should actually be unique. The
> > reason is that Method, Field and Constructor are AccessibleObjects.
> > AccessibleObjects have an setAccessible() method that should only
> > operate on that instance of the Method/Field but not on other
> > Method/Field objects which might refer to the same reflected field,
> > method or constructor.

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.

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

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

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com