JNI without Jni_Lookup() ?

Andrew Haley aph@redhat.com
Mon Apr 19 09:38:00 GMT 2004


Erik Poupaert writes:
 > 
 > Since most java bindings are JNI, and therefore written in plain
 > old C, it's a bit of an uphill battle to do things in CNI and C++.
 > 
 > And in the end, why drag yet another language into the fray? What useful stuff is
 > there that you can do with C++ that you can't with C?

Well, you can describe Java types and methods in C++, and you can't
describe them in C.

"We do not believe that the JNI should be the only native method
interface supported by a given Java VM. A standard interface benefits
programmers who would like to load their native code libraries into
different Java VMs. In some cases, the programmer may have to use a
lower-level, VM-specific interface to achieve top efficiency." 
http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/intro.html#wp16465

The nice thing about CNI is that although it is VM-specific, it is not
lower-level.  I like that.

 > At present JNI has a performance disadvantage compared to CNI,
 > because JNI methods need to get looked up in hashtables, while CNI
 > can be linked statically.

That's a performance disadvantage, but it's only one of several.

 > Now the self-evident question: why not leave the option open to
 > link JNI sources statically, just as CNI sources?
 > 
 > That would speed up all JNI-dependent source trees, reduce their
 > sizes (avoids the need to link whole-archive) and avoid having to
 > maintain bindings in two different, mutually redundant languages.

That doesn't sound unreasonable.  But AFAIK the purpose of CNI support
in gcj is to allow people to use standard CNI libraries, and they're
DSOs.

Andrew.



More information about the Java mailing list