[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Classpath build process and VM-specific issues

From: Archie Cobbs
Subject: Re: Classpath build process and VM-specific issues
Date: Sun, 28 Mar 2004 15:18:25 -0600
User-agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040312

Jeroen Frijters 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 :-()).

I am also working on reference support in JC and have not needed
to modify the java.lang.ref classes at all.

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?

Hmmm.. In JC each Method instance has a private vmData field of type
byte[] containing a pointer to the internal struct _jc_method.
My copies of the reflection classes are different from Classpath's
(there are no VMFoo classes) for various reasons so I guess my
opinion isn't relevant. But in any case for these reasons "no"
I don't agree :-)

I would be interested in a quick poll of VM implementors using Classpath:
do you care more about having fewer diffs with "stock" Classpath or
modifying & optimizing your VM's core classes to eke out optimal

Implementors of the former type would vote "yes" for these kind of changes
while implementors of the latter would vote "no" (as they only serve to
add more diff headaches at the next merge).


Archie Cobbs      *        CTO, Awarix        *

reply via email to

[Prev in Thread] Current Thread [Next in Thread]