Another painful experience is debugging in JNI.

I found ETNUS, a JNI IDE where you can debug Java code and native code in the same environment, but it will cost you some extra bucks. However, the context switching between Visual Studio and Eclipse can be really painful. We explored some hardcore turnarounds like using the "_asm int 3" interruption call on Visual Studio so that we could force an interruption call but that's not elegant.

Conclusion
At this point I hope I've convinced you folks that JNI is definitely the right choice for native code access from a Java desktop application in the scenarios involving, say, graphics and numerics in general. CORBA causes headaches, for example, not being able to bind to the ORB because of a local host Naming Service misconfiguration.

JNI overcomes limitations in Java solutions, especially performance.

Another insight we've had is that accessing a native application through some inter-process technology doesn't benefit much from knowing other designs. In JNI this is a tighter conversation.

Legacy code should be well designed for access through JNI.

If your legacy code isn't modularized, it will very hard to access cleanly from Java or from other languages. The solution proposed in the JVipe scenario was only possible due to the well-designed event-oriented native layer.

So I take the current number of solutions coming out as motivation as industry jumps on JNI support. Let's hope for more JNI support from IDE vendors.

References

• TerraLib - www.terralib.org
• NoodleGlue - www.noodleglue.org
• JNIWrapper - www.jniwrapper.com
• ETNUS - www.etnus.com