RE: Classpath build process and VM-specific issues

[Jeroen Frijters]

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