>>>>> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
Geir> But on a serious note, would it be possible for someone to give a Geir> good technical description of the GNU Classpath VM interface so that Geir> people who aren't aware and for whatever reason can't read it on the Geir> classpath site due to legal reasons can be brought up to speed? The basic idea in Classpath is that all VM decisions are delegated to a set of VM-specific classes. A reference set of classes are provided to make it simpler for a VM to implement the necessary glue. Exactly which things are considered "VM decisions" is decided in an ad hoc way. Typically a VM class will appear in the same package as its users and will use package-private protections so that malicious code can't circumvent security checks. To take a simple example, ClassLoader.defineClass() is a wrapper around VMClassLoader.defineClass(). The latter is a static VM-specific method. In the reference implementation it is declared 'native' (we compile Classpath against the reference implementation). The reason we went this route instead of just requiring each VM to provide its own implementation of each core class (e.g. ClassLoader) is that the classes in question are largely shared code with a very small amount of VM-specific glue. In fact we have a good case study that this tradeoff is the right one in libgcj -- libgcj still provides its own versions of some core classes like String and Object. We periodically have to merge over bug fixes and javadoc and the like. It seems to me that the other classpath-using VMs have it simpler here, as they just require the occasional tweak to their VM classes. Let me know if you want more info. Tom
