I have a few more modifications to the proposal to make, in order to
make it a little more efficient, easier to work with, and binary compatible
across VMs.
We write gnu.vm.VirtualMachineInterface as an interface. We provide
gnu/vm/VirtualMachineInterface.class and the vendor provides a non-abstract
gnu/vm/VirtualMachine.class implementing that interface. This ensures that
they support the method signatures we need, since we provide the interface
they must conform to. It will also allow VM-level detection of errors such
as a 1.2 Classpath being run on a 1.1 VM (VirtualMachine won't implement
enough methods).
I made this change from per-VM packages to just putting the class in
gnu.vm because it seems silly to require vendors to implement a different
package like gnu.vm.japhar and gnu.vm.kaffe. Classes from gnu.vm.japhar and
gnu.vm.kaffe will never ever be used in the same VM. Also because, in the
end, it makes it efficient because the VM's linker can inline those methods
much more easily than with my previous proposal.
Finally, it still allows all of java.* to be distributed separately
from the VM *and* for a single binary distribution to work across multiple
VMs on the same platform. That way, Classpath becomes fully VM-independent,
achieving one of its major goals without sacrificing efficiency.
--John Keiser
