I've put some corrections in, so that its more understandable. Jakob Praher wrote: > Geir Magnusson Jr. wrote: > >>On May 19, 2005, at 5:24 AM, Jakob Praher wrote: > >> >>I don't understand > > Take classpath project. It aims at working accross open vms. So you have > to build a glue layer between what is intrinsic to the vm and what is > expressable in plain java. Classpath has VM classes which are > implemented by the different VMs (mostly public static and often native > stuff), that gets called from within Classpath, so per VM you only have > to reimplement the VM classes. It has pros and cons, if you proceed like > this. For Classpath its the only way to meet the goal of implementing a > whole runtime without knowing exact details of the VM.
> On the other hand > projects like gcj, which have c++ abi for performance reason for most of > the core classes (I mean the really core stuff) - they currently have > libjava - where the whole classpath - but also would like to use the > classpath java classes without importing them into libjava (for code > management and stuff) where appropriate. To state it more clearly: GCJ has a "copy" of classpath in its own tree. In former classpath and gcj haven't worked that closely toghether. Most of the libjava classes are 1:1 copies of the classpath classes. But for some high performance classes / low level classes the gcj team rewrites them. This is a problem if they want to merge the whole classpath tree in. Why did I mention that: This is an example of the VMXxx classes to be to high level - a faster implementation can be done if using CNI (the GCJ native interface that uses C++ ABI). -- Jakob
