classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kaffe and Classpath (again)


From: Nic Ferrier
Subject: Re: Kaffe and Classpath (again)
Date: Thu, 23 Nov 2000 00:16:45 +0000

>>> John Leuner <address@hidden> 22-Nov-00 9:24:12 PM >>>

>The problem is that some VMs (my example being my 
>JVM, kissme) have VM specific stuff in those top classes,
>ie java/lang/Thread and java/lang/Class etc.
>That stuff really should be moved into the VM* classes, but 
>since it is tied in with a whole lot of native code, it's not going

>to be a pleasant experience.

As far as I can see the website advice for VM integrators is pretty
accurate.

The situation is that Classpath has an almost complete java.*
implementation which uses gnu.java.* classes to do the implementation
hidden stuff.

For those java.lang classes I mentioned there needs to be one
implementation for each VM that is integrated. So, using Class as an
example, with current aims there will be:

   japhar/java.lang.Class
   kaffe/java.lang.Class
   eletrical-fire/java.lang.Class
   etc...

Each one of these VM specific versions needs to do certain things to
make Classpath work. Those things seem to be well documented in the
"hooks" section on the VM-integrators page.

It's not too onerous a requirement IMHO to have one set of these
classes per VM.


>At the moment I have just added the Classpath code to my 
>own, merging whatever methods are common by hand. 

That's one approach. I'm going to start by taking the other
approach... changing the Kaffe classes so that they use the Classpath
hooks.

If I can achieve that Kaffe *could* be altered to use adapted
versions of those classes on some configuration request (or even
dynamically but I'm not going to aim for that) and Classpath *could*
include the altered Kaffe classes in the existing:

   vm/kaffe

directory.


What I really need to know about is the history and workings of the
config system.

I presume it's just a system for selecting which version of the
classes under vm/ is compiled into the classes.jar.


The other thing I would quite like to know is more about StackFrame.
As I understand it I have to implement gnu.vm.stack.StackFrame  but
there is a gnu.java.StackFrame as well. 

I would be very gratefull if some classpath old-hand would explain
the intention with all of that. 


Nic



reply via email to

[Prev in Thread] Current Thread [Next in Thread]