classpath
[Top][All Lists]
Advanced

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

Kaffe and Classpath: matching up native code


From: Nic Ferrier
Subject: Kaffe and Classpath: matching up native code
Date: Mon, 07 May 2001 19:22:04 +0100

I've been looking at this again and discovered what I think is an
interesting problem. hopefully airing it here will be of interest to
some and might generate an answer for me.


Classpath abstracts the VM specific interaction into classes:
java.lang.VMxxx. They provide native methods which the VM has to
implement in some way.

Kaffe does things slightly differently. It has native methods that
implement the various VM specific stuff in the same class as the
generic code. But the methods end with a "0". 


eg: kaffe's ClassLoader has a pure java defineClass(...) method which
calls the native method: defineClass0(...).

Classpath's ClassLoader.defineClass(...) calls the method
VMClassLoader.defineClass(...).


What we need to do to get Classpath working with Kaffe is simply
have:

  VMClassLoader.defineClass(...)

map to kaffe's native code which implements:

   ClassLoader.defineClass0(...)

I've got to try and do this with as little fuss as possible. In
particular:

- don't break the Classpath distrib
- don't break the kaffe distrib
- try and use directly as much of kaffe as possible so we avoid
change control problems

This is the problem. I can't see an obvious way of doing this whilst
achieving the above.


In more detail the problem is that the kaffe native code to implement
defineClass0 is written assuming it's going to have a header file
called:

  java_lang_Classloader.h

But from Classpath we'll get:

  java_lang_VMClassLoader.h


I can think of several ways round this, none of them perfect:

1. write an implementation of VMClassLoader that calls kaffe's
classloader implementation native code
Plusses: modular, clean separation, no problems if kaffe changes
Minuses: requires kaffe's javalib impl to be built so javah can be
run to ensure the native code will compile

2. make a Classpath hacked version of the kaffe native code
Plusses: probably simplest option
Minuses: what if the code changes? there is rather a lot of code to
reimplement

3. make VMCLassLoader pure java which calls back to
ClassLoader.defineClass0(...)
Plusses: quite simple, nice kaffe integration
Minuses: forces us to have more vm specific classes for kaffe than
other VMs



Anyone any thoughts or preferences?


Nic Ferrier



reply via email to

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