Re: Proposal for changes to Classpath's JNI libraries

[Tom Tromey]

>>>>> "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.

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.)

These restrictions would seem to greatly limit the usefulness of your
approach.  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.

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

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.

The Classpath jni.h was derived from the libgcj jni.h.  I don't know
what process was used to do it though.  I think the two files ought to
be completely merged.  For one thing the libgcj jni.h has had bug
fixes, and is compatible with the 1.4 specification.

Brian, according to the ChangeLog you did it, with some fixes from
other places.  Can you describe these to me?  Was it just the
DefineClass fix?  I'm willing to add the numbered comments to the
libgcj jni.h change it to use jni_md.h if you do that (i.e., I'll
complete the merge).  Also, why is it `jni.h.in'?  I don't see any
@...@ substitutions in it.

It seems like it would be too hard to construct a simple JNI API
checker -- a simple C file that calls every JNI method.  Then we can
compile this against both the Sun and Classpath jni.h.  Any takers?

Tom