JNI without Jni_Lookup() ?

Erik Poupaert erik.poupaert@skynet.be
Mon Apr 19 01:33:00 GMT 2004


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

Agreed.

I just wish I could have the same with C-based sources. Why can't we have the option
to verify C-based methods at compile time too? Or else, if stuffing methods in
hashtables is such a good thing, why not stuff the C++ methods there too, and slow
them down too?

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

Yes, probably, except for the fact that everybody has written their bindings in C by
now and not in C++, and that the useful tools, such as SWIG, generate C and not C++.
That's where it becomes an uphill battle ...

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

What you can do? Reuse JNI stuff that other people have already done; so that you
don't have to do it again. Without hashtable-lookup performance penalty, preferably.
 
> At least in MinGW, I think we can do JNI statically, can't we? It's been awhile....

It works on linux too. Even though it works, it stays a miserable hack (linking
whole-archive, export-dynamic, -fPIC, treating the exe as a dll, and so on, and so
on), and after all that effort, you get something inherently slow, for no good
reason actually.



More information about the Java mailing list