Java Native Interface (JNI) is a way for java applications to load and invoke DLLs. Because java sources are available for the developer to step into during runtime(I wish we had that too in C#) you could see a lot of JNI calls. For example when you step into java socket you get a JNI call to a C++/C socket.

One would think that it would be easy to call C++ from java, because of the multiple use of it in java itself, but it is NOT.

You need to generate a .H file from the already compiled java class and then implement it with a CPP file and load the DLL from java. The problem is that there is very little the JVM tells you about why it was not able to successfully load the DLL’s.

You get a informative error like “Exception in thread 'main' java.lang.UnsatisfiedLinkError” and a tones of blogs complaining about JNI.

Most examples of JNI load the DLLs in a static block meaning that failure to load causes the classloader to fail and the java class itself does not load to memory.

moreover, multi-disciplinary knowledge is needed to do java-.NET because you need to go via C++.

The bottom line is that JNI and inter-process is not the best practice for  java -.NET interoperability.