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

[Per B. <pe...@bo...>]

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
pe...@bo...   http://per.bothner.com/