Go Common problems and solutions for using JNI under Linux

JNI is an interface between Java and C/s + + programming, which makes it easy to implement Java calls to C + + languages. Specific use methods, there are many tutorials on the Internet, do not do too much introduction. This blog only focuses on common issues in the process of using JNI.

1. Generate header file with command: Javah*.class

This is wrong. Running the above command prompts: Java.lang.IllegalArgumentException:Not a valid class Name:SegNative.class error. The cause of the error is the same as running the program with the Java command, only the prefix can be indicated, without giving the. class suffix.

2. Version issues

Some of the JNI methods in Jdk6 and jdk7 differ slightly, paying attention to conversions. For example, the method of getting a string in C Getstringutfchars is different in two JDK versions. The old Jdk6 version is used in the following ways:

char* name= (char*) (*env)->getstringutfchars (env,name,null);

In Jdk7, the method call becomes:

Const char* Name=env->getstringutfchars (name,0);

Other version problems and function parameter meanings can be obtained by viewing the API for more comprehensive information.

3. The jni.h header file cannot be found by compiling source files with g++

You can use the-I option at compile time to specify the directory where the jni.h header files are located:

g++-i/usr/local/jdk1.7.0_25/include/...

4. Using g++ to compile source files cannot find Jni_md.h

This is because the Jni_md.h header file is referenced in jni.h, and the header file and jni.h are not in a directory, so we also need to specify the Jni_md.h directory:

g++-i/usr/local/jdk1.7.0_25/include/  -i/usr/local/jdk1.7.0_25/include/linux/...

You can see that jni_md.h is placed under directory Linux with Jni.h peers.

5. Dynamic-link libraries are not generated

To generate a dynamic-link library, you need to declare the-shared option at compile time:

g++-i/usr/local/jdk1.7.0_25/include/  -i/usr/local/jdk1.7.0_25/include/linux/segnative.cpp–shared–o lib***. So

In addition, we do not need to be a corresponding. o file, directly specify the name of the dynamic link library.

6. Compiling the dynamic link library error: couldnot read Symbols:bad value

You need to specify an option at compile time:-fpic.

g++-i/usr/local/jdk1.7.0_25/include/  -i/usr/local/jdk1.7.0_25/include/linux/segnative.cpp–shared–o lib***. So-fpic

7. Dynamic link library not found at run time

There are two main causes of this problem:

• The generated dynamic link library has the wrong name: The dynamic-link library We declare in the Java language if it is named a, we need to declare the dynamic-link library name as liba.so at compile time, or we will get an error.
• The path is not correct, and Java cannot find the dynamic link library. Java will look for a dynamic link library in a specific directory, and you can print Java.library.path to see in which directories Java will look for a dynamic link library:

System.out.println (System.getproperty ("Java.library.path"));

My Computer prints the result:

.:/ Opt/intel/impi/3.2.1.009/lib/:/usr/local/cuda/lib/:/root/nvidia_cuda_sdk/lib/:/root/nvidia_cuda_sdk/common/lib /:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

We can see that the relevant Lib is included under this path. It is particularly important to note that the first path is., which means that Java looks for the relevant dynamic link library under the current path. So as long as we put together the dynamic link library and the. class file, there is no problem finding the dynamic link library. If the current directory is not included in the print, we can specify the current directory by modifying Ld_library_path.

In addition, we can specify in the process of running:

Java–djava.library.path= "/home/savedlib/" Executablefile

Using this method, the program can specify a dynamic-link library that is not in the current directory.

Go Common problems and solutions for using JNI under Linux