Mark Wielaard wrote: >I am going through the patches that the Orp developers submitted to >Classpath. The following patch to Method puzzles me: > >2001-12-17 Wu Gansha <[EMAIL PROTECTED]> > > * vm/reference/java/lang/reflect/Method.java: Reimplemented >equals(), refined toString(). > > >Why/When is this neccessary? The comment to equals says: > > Two Methods are semantically equivalent if they have the same declaring > class, name, and parameter list. This ignores different exception > clauses, but since you can't create a Method except through the VM, > this is just the == relation. > >So this comment is wrong for Orp, but when does this happen? >
This comment is also wrong for GCJ, where a new Method object is always created by a getMethod call, since Method is really just a wrapper around an internal reflection data structure. Some VMs may use the Method class as their native/internal representation, and in that case using == would be an optimization. >Maybe we should just mark this method "native" in Classpath and >leave it to the VM implementor. > I don't think it is neccessary to make it native. Method is already part of the VM interface, so VMs can modify it or make it native as they wish. I think the more conservative approach should be taken by the default implementation. regards Bryce. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
