Re: Java-Gnome: jni or cni

[Per Bothner <per at bothner dot com>]

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){
  BODY
}

by:
NATIVE_METHOD(org.gnu.gnomevte.Terminal,
  void vte_terminal_feed (jclass klass, jint handle,
        jbyteArray data, jint length))
{
  BODY
}

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:

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

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
variable.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/