My company develops a client side integration solution to provide uniform access and interaction model to virtually any application, across all heterogeneous platforms - regardless of platform, technology or API's. I am developing code for java integration with other application. The main problem is that developer does not have source code of any application integrated. I wrote (generated with my tool in C++) a huge JNI code for injecting to the running java application, parsing its class object model and making Component wrappers (like COM objects for all component types) to access them from other processes.

In my everyday work I have a good deal ov jni related programming. In my case ov developing BDJ (bluray) player all hardware platform interaction is done using JNI methods. When I joined the project I was surpraised the number of jni methods some classes had... (about 10). As I was merely pure java programmer I decided to refactor some code for removing some native methods. In our project the majority of developers come with a C/C++ background. So they tend to move implementation into native, becase there they can do better then in java.

When I was a Sun engineer writing Java for Trusted Solaris administration I had to use JNI all the time. Writing C JNI code is like serving two masters, the JVM and Solaris. Making sure object references and malloc'd memory had all the T's crossed and I's dotted was the hardest and most interesting part of using JNI. Graham

because to access hardware or hardware specific features it is many times necessary as I don't want to wait for the JVM to evolve to the point where that feature is considered necessary or important. DId a bunch of this in the JOGL, JOAL, JInput, LWJGL space. It would be nice if Sun would look at several of the products out there that make binding to native code stupidly easy and integrate that as a new JNI layer. While many people simply don't need or use JNI, there is no reason why it has to be a complete PITA for those of us who do.

I interface with custom hardware and native video processing software. The hardware interfacing is unavoidable, and quite frankly so is the video processing, since to do it right you must use hand-tuned SIMD instructions in carefully crafted loops or you will get abysmal performance. That's not what Java was made for. And of course there are all the missing bindings to standard things... like burning CDs and DVDs, accessing digital cameras, & scanners, making translucent or non-square windows, ...

What would cost Sun to put normal native interop into Java? Politics... And I have to pay... - Alexey.

Fortunately, that happens only very rarely. Typically, it is to drive some specialised data acquisition card, or for some exotic device control hardware. I've even gone so far as to implement TCP stacks on embedded control devices, just so that I could java.io.Socket instead of JNI.

Java is a platform independant programming language... so, where are the interfaces to use Twain, WIA or Sane? How can I access volume/network share information? Or simply use UPNP to obtain informations about available devices? And no thanks... no commercial and platform dependant 3rd party APIs...

I write JNI like Russell Nash goes to Jersey.