Showing posts with label jni. Show all posts
Showing posts with label jni. Show all posts

Wednesday, August 8, 2012 cannot open shared object file: No such file or directory

In my Ubuntu Linux, I was trying to call Java from C++ using JNI. Compiling progress was succeed but at runtime I saw an error on concole: cannot open shared object file: No such file or directory

Finding the right solution took five seconds but it was quite easy. I modified the LD_LIBRARY_PATH environment variable using export command in the Linux shell:

export LD_LIBRARY_PATH=/usr/lib/jvm/default-java/jre/lib/i386:/usr/lib/jvm/default-java/jre/lib/i386/client

The location of JDK is always changed because of updates but Ubuntu stores the links of current JVM in default-java directory. It is /usr/lib/jvm/default-java in my Linux. Two directories must be added to LD_LIBRARY_PATH. The first one is jre/lib/i386 and the second one is jre/lib/i386/client or jre/lib/i386/server in default-java directory. Use of export solves my problem.

Good luck!

Wednesday, January 18, 2012

When to use Java Native Interface (JNI) ?

Programming in Java is totally fun, especially, if you use it for general purposes. The term 'general purposes" is stated here as "the program that needs file, socket, web, gui operations" opposite to a special problem. That is, a special problem may be a scientific one which requires loops, array operations and basic operations. A program like this can be easily written in other languages.

Sometimes, we need other libraries which are not yet implemented for Java or some operations that perform some low level operations which are not handled by the JVM. For instance, a library written in C can not be directly used in Java. You have to either re-write it in Java or use the Java Native Interface (JNI).

But there is something worth to talk about. People generally think that a native function that called from Java must run faster than in Java. But it is not true. Yes, a native function (we use the term native for compiled codes) may run faster and via versa. The important point here is that Java can not directly perform a function call directly, that is, there is some preparation process needed.

To be clear, let me give an example. Suppose that we have a C++ function 'mean' which stands for calculating the arithmetic mean of a double array. We have also a function 'jmean' which is written in Java for the same purpose. Now, suppose that we have a double array with size of 1,000,000 and has values from 0.0 to 999,999.
The processes of passing this array reference to C++ and getting the calculated result costs 112 milliseconds. When I tried the same test for the function written in Java, I got the result of 10-12 milliseconds. It seems there is a significant performance difference between them!

In this example, the biggest amount of time is consumed by the calling preparation, not the calculation mean itself.

We can summarize those results as :
1) Calling a native method for millions times makes a significant performance loss.
2) Use JNI if you have to. Maybe, if it is performing a low level operation or converting the C code to Java is hard. For example accessing to LPT port is not possible in Java and you need to use JNI here.

and I can personally say that:
"An increase on performance depends on the job performed by the native method."

Finally, the old book, Essential JNI - Java Native Interface is a good book if you really interested in JNI. JNI is generally used for calling C/C++ functions from Java and accessing Java objects from C/C++. JNI also stands for "creating JVM's in C/C++" code and that means you can manipulate java programs as acting like the JVM itself.

JNI is in everyday Java life. JCurses library uses JNI for coloured console for the people who got bored using System.out.println. QJambi uses JNI for constructing a bridge between Java and Qt classes. Java's standard libraries such as AWT also bridges between native GUI API's and Java. Charva uses JNI for GUI'd text terminals. And, of cource, there are lots of examples on this.