Mark Wielaard wrote: > I admit not to have looked into or thought about java.lang.ref support > yet. How many VMs based on GNU Classpath properly implement those?
I have a (sort of) working implementation. I had to replace java.lang.ref.Reference (and I use instanceof to detect PhantomReference (all the others are implemented the same :-()). Since java.lang.ref.Reference is such a simple class, I don't see much point in providing a VM split. > java.lang.reflect should be refactored. I don't think there is a real > reason for a VM to have specific versions of those (given properly > designed VM interfaces of course). But I don't have had time > yet to work on it. Agreed. I have some ideas, but would like feedback from others to see it they would work for them. I think that in this case (contrary to Class - VMClass) it makes sense for everyone to have a VMMethod instance, because Method contains state (the setAccessible flag). Does everyone agree with this, or are there good reasons not to have a VMMethod instance? Method.invoke() is tricky. How much should be done in Method vs. VMMethod? For example, I don't need argument widening (the underlying reflection implementation does that already), but others might want to share that and sharing is more convenient if it is in Method. BTW, before Method.invoke() can be implemented, we need to have a getCallerClass. Regards, Jeroen _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
