That sounds like a perfectly reasonable pattern. Graeme's earlier description [1] is a coarse grained approach, which says if the class has a close VM dependency then we leave it up to the VM-implementor to provide it ;-) For types like Object that is not onerous since there is not much behavior in the common code, but I can see that, say, String has enough reusable code that externalizing the VM part into a VMString type makes sense rather than copying another impl.
[1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200507.mbox/[EMAIL PROTECTED] Regards, Tim David P Grove wrote: > 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. > > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.