OK, only one more change.
There could be problems with class resolution using the class below.
Instead, this is best:
public class System {
public static final VirtualMachine vm = getCurrentVM();
public static VirtualMachine getCurrentVM();
}
This way, vm is never null, not even at the very very beginning.
--John Keiser
> -----Original Message-----
> From: John Keiser [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, August 16, 1998 2:07 PM
> To: Paul Fisher; Classpath
> Subject: RE: VM Class Templates
>
>
> 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]
> >
> >
>
>
