JNI without Jni_Lookup() ?

[Mohan Embar]

Hi Erik,

I'm not a low-level gcj hacker, but:

>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++.

I personally like CNI a lot. For me, being able to verify method signatures at
compile time instead of runtime is the same kind of good feeling that I don't
get when doing the sort of creepy, dynamic, runtime method resolution you
get with JNI, Smalltalk, JavaScript or what have you. I'm not saying that JNI
isn't good or that it doesn't have its place, just that CNI is a way more natural
fit for Java/C++ integration.

I basically agree with this section of the CNI documentation (except
that Java's reflection metadata changes the game quite dramatically IMO):

--------------------------------------------------------------------
>From an implementation point of view we can consider Java to be a subset
of C++. Java has a few important extensions, plus a powerful standard class
library, but on the whole that does not change the basic similarity. Java is a
hybrid object-oriented language, with a few native types, in addition to class
types. It is class-based, where a class may have static as well as per-object
fields, and static as well as instance methods. Non-static methods may be
virtual, and may be overloaded. Overloading in resolved at compile time by
matching the actual argument types against the parameter types. Virtual
methods are implemented using indirect calls through a dispatch table
(virtual function table). Objects are allocated on the heap, and initialized
using a constructor method. Classes are organized in a package hierarchy.

All of the listed attributes are also true of C++, though C++ has extra
features (for example in C++ objects may also be allocated statically or in a
local stack frame in addition to the heap). So the most important task in
integrating Java and C++ is to remove gratuitous incompatibilities.
--------------------------------------------------------------------

>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?

What can you do with C that you can't do with assembler? I love virtual
methods, stack-based destructors, private and protected methods. I can
mimic all of these in C / assembler, but with tons more work and less naturally.
Why would I want to inflict this on myself?

>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. Now the
>self-evident question: why not leave the option open to link JNI sources statically,
>just as CNI sources?

At least in MinGW, I think we can do JNI statically, can't we? It's been awhile....

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/