Re: Kaffe and Classpath: matching up native code

[John Keiser]

Things are designed more for the first option ... that's how we're handling
Japhar for example.  Sun apparently uses the "methodName0" convention as
well, so we just call back into those methods when possible.

--John

----- Original Message -----
From: "Nic Ferrier" <address@hidden>
To: <address@hidden>
Sent: Monday, May 07, 2001 12:22 PM
Subject: Kaffe and Classpath: matching up native code


> 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
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath