> -----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?
>
Now you've come full circle, though. You're talking about conditional
compilation based on the VM.
If you want that, how about this:
public interface gnu.vm.VirtualMachine {
all VM specific functions, including Runtime and System and Class ... not
that many in total, no more than 30 or 40.
public abstract String getVMName();
public abstract int[] getVMVersion();
}
public class gnu.vm.System {
public static VirtualMachine getCurrentVM();
}
Provided with GNU Classpath are: all classes and native methods under
java.*, and gnu.* except gnu.vm. In gnu.vm we provide gnu.vm.VirtualMachine
and any other supporting interfaces (but no actual implementations of any
functions). gnu.vm.System is implemented by the VM, as well as the
appropriate implementation of gnu.vm.VirtualMachine. This gets around the
conditional compilation of Classpath and lets the same distribution run on
multiple VMs.
I like the idea of the interface dispatch in Java because an efficient Java
linker has the ability to inline the code it calls if it so wishes, which a
C linker does not (at least not easily). This is a good solution, better
than mine, and does not cost the overhead if a good linker is used.
One remaining issue: if we go this way, we create java.lang.reflect, and
therefore we are responsible for the JNI functions
To/FromReflectedField/Method. Not too big a problem, but it does kind of
blur the lines of responsibility a bit again. There may be other issues,
but for the most part I'm satisfied with your solution.
If you really want to have different classes -- gnu.vm.Runtime, System,
etc., then have gnu.vm.System return things like getCurrentRuntime(),
getCurrentSystem(), etc. (Obviously you'd have to rename gnu.vm.System in
this case.)
> --
> Paul Fisher * [EMAIL PROTECTED]
>
>
