JNI

JNI libraries are named with the library name used in the System.loadLibrary method of your Java code prefixed by lib and suffixed with .jnilib. For example, System.loadLibrary(“hello”) loads the library named libhello.jnilib.

If you are developing a Cocoa Java application, you need to load your JNI library using a different mechanism. If your library is called hello.jnilib, you should call System.load(NSBundle.mainBundle().pathForResource(“hello”, “jnilib”, “Java”)); Note that this assumes that your library is located in Resources/Java/.

In building your JNI libraries, you have two options. You can either build them as bundles or as dynamic shared libraries (sometimes called dylibs). If you are concerned about maintaining backward compatibility with Mac OS X version 10.0, you should build them as a bundle; otherwise you probably want to build them as a dylib. Dylibs have the added value of being able to be prebound, which speeds up the launch time of your application. They are also easier to build if you have multiple libraries to link together.

To build as a dynamic shared library, use the -dynamiclib flag. Since your .h file produced by javah includes jni.h, you need to make sure you include its source directory. Putting all of that together looks something like this:

cc -c -I/System/Library/Frameworks/JavaVM.framework/Headers sourceFile.c

cc -dynamiclib -o libhello.jnilib sourceFile.o -framework JavaVM

To build a JNI library as a bundle use the -bundle flag:

cc -bundle -I/System/Library/Frameworks/JavaVM.framework/Headers -o libName.jnilib -framework JavaVM sourceFiles

For example, if the files hello.c and hola.c contain the implementations of the native methods to be built into a dynamic shared JNI library that will be called with System.loadLibrary(“hello”), you would build the resultant library, libhello.jnilib, with this code:

cc -c -I/System/Library/Frameworks/JavaVM.framework/Headers hola.c
cc -c -I/System/Library/Frameworks/JavaVM.framework/Headers hello.c
cc -dynamiclib -o libhello.jnilib hola.o hello.o -framework JavaVM

Often JNI libraries have interdependencies. For example assume the following:

* libA.jnilib contains a function foo().
* libB.jnilib needs to link against libA.jnilib to make use of foo().

Such an interdependency is not a problem if you build your JNI libraries as dynamic shared libraries, but if you build them as bundles it does not work since symbols are private to a bundle. If you need to use bundles for backward compatibility, one solution is to put the common functions into a separate dynamic shared library and link that to the bundle. For example:

1. Compile the JNI library:
cc -g -I/System/Library/Frameworks/JavaVM.framework/Headers -c -o myJNILib.o myJNILib.c

2. Compile the file with the common functions:
cc -g -I/System/Library/Frameworks/JavaVM.framework/Headers -c -o CommonFunctions.o CommonFunctions.c

3. Build the object file for your common functions as a dynamic shared library:
cc -dynamiclib -o libCommonFunctions.dylib CommonFunctions.o

4. Build your JNI library as a bundle and link against the dynamic shared library with your common functions in it:
cc -bundle -lCommonFunctions -o libMyJNILib.jnilib myJNILib.o

A complete example of calling a dynamic shared library from a bundle, including both a makefile and an Xcode project, can be found at http://developer.apple.com/samplecode/JNISample/JNISample.html.

Note: When building JNI libraries, you need to explicitly designate the path to the jni.h. This is in /System/Library/Frameworks/JavaVM.framework/Headers/, not /usr/include/ as on some other platforms.

Note: Once you have built your JNI libraries, make sure to let Java know where they are. You can do this either by passing in the path with the -Djava.library.path option or by putting them in /Library/Java/Extensions/.