>>>>> "Stephen" == Stephen Crawley <[EMAIL PROTECTED]> 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
