[Top][All Lists]

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

Re: Proposal for changes to Classpath's JNI libraries

From: Tom Tromey
Subject: Re: Proposal for changes to Classpath's JNI libraries
Date: 02 Dec 2002 20:27:55 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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

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 `'?  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?


reply via email to

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