Yes. The main focus of the Jikes RVM project is VM/JIT research. We've made minor contributions to the design of the GNU classpath VM/classlib interface, since we are one of the many runtimes that depend on it, but we're mainly consumers of class libraries, not producers. As discussed in more detail in the paper Mark cited below, Jikes RVM did switch from the OTI libraries to GNU Classpath in 2002/2003. The switch was made both because GNU classpath was open source, and this more available to our users, and because at the time, GNU classpath provided the functionality we needed to be able to run Eclipse on Jikes RVM.
In my opinion, the main thing to learn from the GNU classpath library interface is that the pattern of having a Foo.java which delegates any potentially VM-specific functionality to a VMFoo.java works quite nicely. In classpath this has evolved to include all native methods being defined on VMFoo classes instead of on Foo directly. GNU classpath supports a fairly diverse set of client runtimes and this pattern developed as the most natural way for letting various runtimes provide customized, high-performance implementations of the VM-specific functionality. The last time this came up, the discussion quickly devolved into an argument about whether the package prefix should be java.lang.VMFoo or org.harmony.vm.lang.VMFoo. I personally think both sides had some valid points, but to me the package prefix is actually a secondary issue (and one could hope that JSR 277 would eventually provide better mechanisms to provide unsafe APIs to the internals of the class libraries while preventing them from being used directly by general applications. GNU Classpath does this by using basic Java language mechanisms (VMFoo classes are package scoped), other VMs do it via classloader hackery. IMO neither option is very satisfying.). The main point is that for maximal flexibility and performance the class libraries should talk to the VM through a well-specified, Java-only interface. Don't assume that the VM would prefer being talked to by the class libraries via native methods, or a struct of "C" function pointers. If this is true for a VM, then it can implement the VMFoo classes with a trivial wrapper implementation that does exactly that (one could even be provided as part of the class libraries; GNU classpath provides default implementations of most of its VMFoo classes that use native methods/JNI). --dave Tim Ellison <[EMAIL PROTECTED]> wrote on 07/24/2005 04:11:25 PM: > Indeed. IBM has multi and varied interests in all aspects of Java. I > think of the Jikes folk as VM developers rather than class library > developers, but I may be doing them an injustice because I'm not > familiar with their classpath contributions. > > Regards, > Tim > > > Mark Wielaard wrote: > > Hi, > > > > On Fri, 2005-07-22 at 11:44 +0100, Tim Ellison wrote: > > > >>There are two distinct groups within IBM doing class library work -- > >>hey, it's a big place! > >> > >>One group provides a robust J2SE based on the Sun libraries for many IBM > >>products/platforms [1]. The other group has no access to Sun code and > >>provides a (similarly robust <g>) smaller set of IBM-authored libraries > >>for embedded product offerings [2]. > > > > > > You seem to forget group 3 (wow, IBM is big!) that produced JikesRVM and > > that actually switched from those robust IBM-authored libraries to GNU > > Classpath <double g!> :) > > > > IBM research published an interesting paper about this that is worth a > > read. > > > > The Jikes Research Virtual Machine project: Buliding an open-source > > research community > > B. Alpern, S. Augart, S.M. Blackburn, M. Butrico, A. Cocchi, P Cheng, J. > > Dolby, S. Fink, D. Grove, M. Hind, K.S. McKinley, M. Mergen, J.E.B. > > Moss, T. Ngo, V. Sarkar, and M. Trapp. > > IBM Systems Journal, Vol 44, No 2, 2005. > > > > http://www.research.ibm.com/journal/sj/442/alpern.pdf > > > > Cheers, > > > > Mark > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK.
