Stephen Crawley <[EMAIL PROTECTED]> writes: > Third (and I hope final) take. This round I've done the following: > > * added the JNI 1.4 methods in stead of placeholders > > * removed the _JNINATIVEMETHOD #ifdef'ing. [This is no longer > necessary for Kissme, which now uses a different struct to > hold native methods internally.] > > * removed the #include of config.h, and modified configure.in > to directly substitute the "#define JNI_EXTENSION" into jni.h > > * commented the JNI_EXTENSION macros
I like this version much better. I have still just one problem with the idea (not the implementation at this point). It would help me to understand what you think of this counter proposal before proceeding. As mentioned before privately, the extra functions a VM might want to expose to JNI do not need to be in this JNI function table. An example from Sun used for the JVMPI, which I'm interested in trying to make it easier for free VMs to support, uses a structure to define a function call interface accessed via JNI through GetEnv. Would something like this make the JNI_EXTENSION related parts of your patch unnecessary? http://java.sun.com/products/jdk/1.2/docs/guide/jvmpi/jvmpi.html Brian -- Brian Jones <[EMAIL PROTECTED]> http://www.haphazard.org/~cbj/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
