[Java-gnome-developer] Re: Java-Gnome: jni or cni

Per Bothner per@bothner.com
Sat Mar 13 22:47:00 GMT 2004

I think it is a good idea to keep JNI support, but provide
CNI using a hybrid approach.

For example we can replace:

JNIEXPORT void JNICALL Java_org_gnu_gnomevte_Terminal_vte_1terminal_1feed
   (JNIEnv *env, jclass klass, jint handle, jbyteArray data, jint length){

   void vte_terminal_feed (jclass klass, jint handle,
         jbyteArray data, jint length))

or (more editor-friendly):

NATIVE_METHOD(org.gnu.gnomevte.Terminal) void
vte_terminal_feed (jclass klass, jint handle,
         jbyteArray data, jint length)

then a pre-processor can generate the JNI or CNI headers.
Note this would have to be an intelligent pre-processor, that
goes beyond cpp, since it needs to "mangle" method names etc.

The generated CNI code might be:

(jclass klass, jint handle, jbyteArray data, jint length)
   JNIEnv *env
      = _Jv_GetJNIEnvNewFrame(&org::gnu::gnomevte::Terminal::class$);

The preprocessor only needs to call _Jv_GetJNIEnvNewFrame if the
env parameter is used, of course.

This initial step still uses JNI for the method bodies, but
it is still a performance improvement (since we don't need the
Java-to-JNI trampoline), and simplifies usage compare to true JNI,
since the native code can be linked in the same library as the
Java code.  Performance-critical methods can contain #ifdef CNI
sections. We can also incrementally improve the preprocessor wit
extra functionality.  For example many of the JNI callback functions
are just wrappers for CNI functions, so a simple conversion can
convert those, possibly removing the need for the JNIEnv
	--Per Bothner
per@bothner.com   http://per.bothner.com/

This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
java-gnome-developer mailing list

More information about the Java mailing list