Oops, one last thing about that message:
We should define gnu.vm.System differently, for efficiency:
public class System {
public static final VirtualMachine vm;
}
As long as the gnu.vm.System class is loaded first, and the VM sets the vm
variable appropriately, there will be no problem. We can even provide the
gnu.vm.System class ourselves in this case, and all the VM would provide
would be things under gnu.vm.VIRTUAL_MACHINE_NAME, which we would never have
to know anything about.
--John Keiser
> -----Original Message-----
> From: Paul Fisher [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher
> Sent: Sunday, August 16, 1998 11:53 AM
> To: Classpath
> Subject: Re: VM Class Templates
>
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > Comments?
>
> I don't particularly like the template idea -- mainly because Java
> doesn't support the notion of templates. It's not nicely abstracted,
> and it leaves room for error.
>
> So, here's a new proposal, based on interface dispatch. Tell me what
> you think. :)
>
> VM dependent classes delegate calls to interfaces defined in package
> "gnu.vm". These interfaces must be implemented by a VM in order for
> it to work with GNU Classpath. Implementations of "gnu.vm" are housed
> in a packaged called "gnu.vm.<VIRTUAL_MACHINE_NAME>", where
> <VIRTUAL_MACHINE_NAME> is the name of the virtual machine.
>
> For example, here's the full source code for gnu.vm.Runtime:
>
> public interface gnu.vm.Runtime {
> public void exit(int status);
> public void runFinalizersOnExit();
> public void gc();
> public void runFinalization();
> public void traceInstructions(boolean on);
> public void traceMethodCalls(boolean on);
> }
>
> Here's a segment of GNU Classpath's java.lang.Runtime:
>
> public class Runtime extends Object {
> static gnu.vm.Runtime run = new gnu.vm.VIRTUAL_MACHINE_NAME.Runtime();
>
> public void exit(int status) {
> run.exit(status);
> }
> }
>
> At compile time, VIRTUAL_MACHINE_NAME is resolved to the correct class
> name through the use of the C preprocessor. The value of
> VIRTUAL_MACHINE_NAME is determined via autoconf.
>
> So for Japhar, a stack trace might look like:
>
> 1: gnu.vm.japhar.Runtime.exit(0)
> 0: java.lang.Runtime.exit(0)
>
> Using an interface dispatch scheme results in an extra Java function
> call for each VM specific call. This allows freedom in the VM
> specific code, as it has been abstracted from GNU Classpath. The VM
> specific code is free to do anything that it so desires. For example,
> there's no requirement for the native code in the VM classes to be
> JNI. The extra layer of abstraction allows each VM to live in its own
> separate namespace, unaffected by changes to non gnu.vm classes.
>
> Let's say for instance your name begins with a "J", and ends with
> "ohn". You might not like the _one_ extra function call overhead. No
> problem, just write a bytecode muncher which inlines all the VM
> specific code into the core Java classes after compilation of GNU
> Classpath.
>
> Comments?
>
> --
> Paul Fisher * [EMAIL PROTECTED]
>
>
