Re: Method.equals() question

[Chris Gray]

On 1 Mar 2003, Mark Wielaard wrote:

> Hi,
> 
> On Fri, 2003-02-28 at 21:58, Archie Cobbs 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.

Yup. What we are doing is to compare (in native code) the Method `wotsit',
which is a pointer to the internal data structure used by the VM. We have 
to go native to do this because the wotsit is not visible at the Java 
level. 
> 
> I have wanted to add some Mauve tests for this since it is an easy thing
> to overlook. Have put that a bit higher on the TODO list now :)
> 
> As a consequence some of the reflect classes have to be carefully
> examined to make sure that they do not make the assumption that equals
> means same reference. (Note that in contrast each Class object should
> have the property they are unique.)

Sounds like a good idea: nasty things could happen if calls to 
setAccessible() were to interfere with one another. With regard to the 
Class objects, bear in mind that e.g. java.lang.String should be the same 
object whatever class loader you use, whereas for user-defined class 
loaders there can be as many classes with a given name as there are class 
loader instances.


-- 

Chris Gray

VM Architect, ACUNIA