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
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
