Hi, On Sat, 2004-03-27 at 00:56, Steven Augart wrote: > Etienne Gagnon wrote: > > [Some VMs, like JikesRVM tend to completely replace some base classes > > by their own; SableVM does not]. > > Jikes RVM's rvmrt.jar overrides exactly eleven non-VM* classes from a > default Classpath installation's glibj.zip: > > java.lang.Class > java.lang.Object > java.lang.Thread > java.lang.Throwable > java.lang.ref.PhantomReference > java.lang.ref.Reference > java.lang.ref.SoftReference > java.lang.ref.WeakReference > java.lang.reflect.Constructor > java.lang.reflect.Field > java.lang.reflect.Method
I like to know what prevents JikesRVM currently from sharing these classes. I hope to go to a model like SableVM apparently has were none of the core classes need to be overridden (even though some VMs might still opt to do it anyway). I had hoped that the VM interface for Class, Object, Thread and Throwable was usable for most VMs. What isn't in your case? 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? 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. Hopefully some of the work done by the SableVM hackers will help here. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath