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
[EMAIL PROTECTED] http://per.bothner.com/
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
