JNI without Jni_Lookup() ?

[Erik Poupaert]

> I think I see your concern now - about the reuse. In your experience, have the
> slowdowns due to JNI's efficiencies been noticeable?

I haven't been benchmarking personally, but I certainly have read the following
alarming statements:

http://www.gnu.org/software/classpath/docs/hacking.html


"""
You might think that using native methods all over the place would give our
implementation of Java speed, speed, blinding speed. You'd be thinking wrong. Would
you believe me if I told you that an empty interpreted Java method is typically about
three and a half times faster than the equivalent native method?

Bottom line: JNI is overhead incarnate. In Sun's implementation, even the JNI
functions you use once you get into Java are slow.
...
GetMethodID(), GetFieldID(), and FindClass() are *slow*.
...
Here are a few tips on writing native code efficiently:
Make as few native method calls as possible.
...
Cache methodIDs and fieldIDs wherever you can. String lookups are expensive. T
"""

Storing methods in hashtables, disadvantages:
(1) very slow
(2) bloats the executable's footprint 
(3) makes it impossible to verify anything at compile time
advantages:
none