This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: JNI without Jni_Lookup() ?
> 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.