Disadvantages of using Java Native Interface

Question

I can not get these two disadvantages of using JNI. I want to know more about them:

• Difficult to debug runtime error in native code

• Errors i

Answer 1

You'll lose one of the advantages of using Java, your application is not platform independent anymore, and many other problems implied from that: maybe you'll be supporting DLLs for Windows and .so files for Linux, each one of them with their own compiler, different debugging tools, different dependencies and maybe different bugs, more complexity for your build process, more code to test, etc.

Answer 2

While this shouldn't be the case in theory, in practice, JNI based code I found to be very brittle -- I've found it to be a maintenance nightmare. Small changes or even just JVM upgrades cause obscure problems. This may have improved with more recent Java versions (I'm harking back to JDK 1.3 or earlier here).

Answer 3

Difficult to debug

• You need a C / C++ debugger to debug the native code. It's not possible to step through from Java to C/C++ code easily. (though it is possible to debug both simultaneously. I've done it with Eclipse and the CDT plugin, but it's a pain)

Errors in JNI

• Bad C/C++ code in your native library can / will cause core dumps / segmentation faults that the JVM can't recover from, so your whole app crashes.

Answer 4

Difficult to debug runtime error in native code

Have you ever seen a stacktrace in Java? Well they are very user friendly and they tell you most of the times, the line number, class method and what failed. You don't have those on Native code.

Errors in JNI code take down the entire JVM and don't provide any mechanism for graceful recovery

When you run java code, all is run under the control of the JVM, if something goes wrong, the JVM can handle it. You don't have that control using Native code.

Answer 5

I'm not sure about JNI, but if you're using JNA, you can set Native.setProtected(true) and it will throw an error instead of crashing the JVM, so that you can catch it in try...catch block. So second disadvantage is not a problem. (see source code)

Answer 6

I'm not sure if this helps, but I used a native method to set a static flag in my JNI/C code to turn debug tracing on or off (default is off). Then I used good old printf() calls at the start of each JNI function that only executed if the flag was set. It's crude but it works.

It's also a good idea to provide some kind of version checking between the Java class and its JNI functions. This can be done with a JNI function that gets called from a static class initializer block. If the client has the wrong combination of libraries (i.e., the jarfile got updated but the JNI shared library didn't, or vice versa), you can throw an exception at class load time.