Re: Proposal for changes to Classpath's JNI libraries

[Stephen Crawley]

> >>>>> "Stephen" == Stephen Crawley <address@hidden> writes:
> 
> Stephen>   3) Some other tweaking is required so that
> Stephen>   classpath/include/jni.h can be #included by Kissme VM code.
> Stephen>   (We need to disable the declaration of certain JVM
> Stephen>   implementation-specific types as "void *" ...)
> 
> JNI is supposed to be binary-compatible across implementations.
> In general, modifying JNI is a no-no.

In principle I agree.  However, we have this (hopefully) short term
problem in Kissme ... yadda, yadda

[Besides, it is not clear that it matters much to anyone right now.  The
current releases of Classpath, GCJ and Kissme >>all<< have JNI function
vectors that are incompatible with JNI 1.0.  The fact that nobody noticed
until now tells me something about the relative importance of these things.]

> Your patch is probably ok as long as your implementation declares a
> new version number and only returns an interface object with the new
> methods if that version number is specified.  Of course you have to
> make sure to pick a version number that Sun is unlikely to pick.
> (These additions already clash with the 1.4 JNI additions.)

That is a good point.  I will see to it that we use a different version
number.

> These restrictions would seem to greatly limit the usefulness of your
> approach.

This is true.  And I hope that we can remove the need for this "hack"
in the long term by making the Kissme native methods GC safe. 

> Why bother with JNI at all?  If it is going to be
> Kissme-specific, just put the calls directly in the code and be done
> with it.

In the long term, (strict!) compliance with the JNI API spec is likely
to be important to Kissme users.  So this is one reason to continue
using JNI now, even though we are bending it a bit.  Another reason is
that if we didn't use JNI, we'd be forced to implement/maintain our own
native methods.

-- Steve

> If we go either of these routes, doesn't it mean that every change to
> JNI code will have to be tested against Kissme?

We (the Kissme maintainers) can take care of that.  IMO, it is unlikely
that my proposed changes would make this any more work than tracking
Classpath changes currently is.

> Stephen> [* Actually, the patches also fix a bug in
> Stephen> classpath/include/jni.h.  A couple of JNI functions have been
> Stephen> transposed ... according to the Sun JNI 1.2 spec.]
> 
> FWIW, I don't agree with that part of the patch.  I'm looking here:
> 
> http://java.sun.com/products/jdk/1.2/docs/guide/jni/spec/functions.doc.html#15986
> 
> This describes:
> 
>     jclass DefineClass(JNIEnv *env, const char *name, jobject loader,
>                        const jbyte *buf, jsize bufLen);
> 
> This is what is in Classpath (not libgcj though -- oops).
> This is also in the IBM JDK jni.h.

Hmmm ...

In the JDK 1.4.0 documentation for JNI I downloaded from Sun a few months ago:

    jclass DefineClass(JNIEnv *env, jobject loader, 
                       const jbyte *buf, jsize bufLen); 

The current Kissme version of jni.h defines:
    jclass DefineClass (JNIEnv* env, jobject loader,
                        const jbyte* buf, jsize bufLen);

But ... in the JDK 1.4.0 documentation on the Sun website (today):

    jclass DefineClass(JNIEnv *env, const char *name, jobject loader, 
                       const jbyte *buf, jsize bufLen);

Something strange going on here!  Perhaps DefineClass is defined
differently by Sun on different platforms??

-- Steve