< Previous PageNext Page > Hide TOC

Core Java APIs and the Java Runtime on Mac OS X

This article discusses the differences between the Core Java APIs on Mac OS X and other platforms. In general, the Core Java APIs behave as you would expect them to on other platforms, so most of them are not discussed in this article. There are a couple of details concerning Preferences that you should be aware of, as discussed in “Other Tools.”

Contents:

Networking
Preferences
JNI
The Java Runtime


Networking

Mac OS X v10.3 and later supports IPv6 (Internet Protocol version 6). Because J2SE 5.0 and Java SE 6 use IPv6 on platforms that support it, the default networking stack in Mac OS X is the IPv6 stack. You can make Java use the IPv4 stack by setting the java.net.preferIPv4Stack system property to true.

Preferences

The Preferences API is fully supported in Mac OS X, but there are two details you should be aware of to provide the best experience to users:

JNI

It is recommended that you use the Java JNI Application template in the Xcode Organizer as a starting point for your JNI development. For more on the Xcode Organizer, see “The Xcode Organizer.”

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. Java HotSpot also recognizes .dylib as a valid JNI library format as of Mac OS X v10.5.

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

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:

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

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

Note: After you have built your JNI libraries, make sure to let Java know where they are. It is recommended that you do this by putting your libraries into your application bundle and passing in the path with the -Djava.library.path option. It is also possible to do this by putting your libraries in /Library/Java/Extensions/, but this is discouraged, as it breaks the encapsulation of your bundle.

A complete example of JNI development can be found in the MyFirstJNIProject sample code. More details on JNI can be found in Tech Note TN2147: JNI Development on Mac OS X.

The Java Runtime

The Java implementation for Mac OS X includes the Java HotSpot VM runtime and the Java HotSpot client VM, both from Sun. The VM options available with the Java VM in Mac OS X vary slightly from those available on other platforms. The available options are presented in Java Virtual Machine Options.

Table 1 lists the basic properties of the Java VM in Mac OS X. You can use System.getProperties().list(System.out) to obtain a complete list of system properties.

Table 1   JVM properties

Property

Sample value

Notes

java.version

1.5.0_13

Mac OS X v10.4 and earlier ships with earlier versions of Java. Use this property to test for the minimal version your application requires.

java.vm.version

1.5.0_13

file.separator

‘/’

Note that this is a change from Mac OS 9.

line.separator

‘\n’

This is consistent with UNIX-based Java implementations, but different from Mac OS 9 and Windows.

os.name

Mac OS X

Make sure to check for Mac OS X , not just Mac OS because Mac OS returns true for Mac OS 9 (and earlier) which did not even have a Java 2 VM.

os.version

10.5.4

Java 1.5 runs only in Mac OS X v10.4 or later.

Note :  The mrj.version system property is still exposed by the VM in Java 1.5. Although you may still use this to determine if you are running in the Mac OS, for forward compatibility consider using the os.name property to determine if you are running in Mac OS X. The reason is that this property may go away in future attempts to further synchronize the Apple source with the source from Sun.



< Previous PageNext Page > Hide TOC


© 2003, 2008 Apple Inc. All Rights Reserved. (Last updated: 2008-10-15)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.