The Future of Native Interfaces
I got a lot of questions about JNI after my Mac OS X for Java Geeks book was published. I just wrote an article for ONJava, Mac OS X JNI Revisited. While writing the article, I was mostly focused on answering reader questions, but as I was working, I started to wonder why JNI development was just so hard.
When I was working at Apple, there was some interesting work done on native integration called JDirect (I believe that Patrick Beard was the one who came up with the idea). It's been a while (five? six years?) but my recollection was that basically the JVM was smartened up enough to call native libraries without the JNI cruft - especially nice for using existing native system libraries (I believe mostly CFM) for things like QuickTime integration.
I seem to recall more than one complaint that it was "too easy" to integrate native functionality.
The latest JDK 1.4.1 release from Apple removed JDirect functionality after being deprecated for quite some time. One of the big problems with JDirect was that it was Mac OS only, and while there was at least some notion of Microsoft including a similar technology in their JVM, it obviously never got rolled back into the JDK proper.
Probably the biggest problem with the current javah-based package is the tremendous difficulty using existing native libraries - there's no reverse version of javah that sucks up existing header files and produces a set of Java classes filled with native keywords that automatically binds.
I'll be blunt - I don't know if that's the sort of thing that ought to be included in the JDK or not. Maybe it's a feature for a C/C++ linker - to automatically generate the bindings as a side product if fed a particular flag. Or, maybe this is something best handled by xdoclet/ant/maven, at least automating some of the drudgery of adding new signatures to your C/C++ library as you add new native code?
So, I guess the question really is, is there a place for improving these native integration tools? Should it be done in the JVM itself, in the JDK tools, or as an external project? Or is there even enough interest in Java-native bridging for it to matter - it's possible now, there's a bit of a steep learning curve, and that's just ok?
Oh, and as a final note - somebody asked about REALbasic, which of course bring up the whole concept of bridging non-C/C++ code with Java. Visions of SOM, DSOM, and CORBA leap to mind... someday the nightmares will stop...