< Previous PageNext Page > Hide TOC

Multiple Versions of Java

This release marks a break with tradition for Mac OS X and Java. In previous releases there could only be one version of Java installed on the system. Developers only needed to be concerned with a single Java version for a particular version of Mac OS X. With the Java 1.4.1release, there is the possibility that users will have two different versions of Java on their system. As a developer you need to take this into account for both future development and support of existing Java applications.

Note that there are only two versions of Java when a user has explicitly installed Java 1.4.1. If a user has not explicitly installed Java 1.4.1, they will have only Java 1.3.1, and any 1.4.1-specific code will not work. They can download Java 1.4.1through Software Update or from http://www.apple.com/downloads/macosx/. As a developer, there are many ways you can determine whether Java 1.4.1 is installed, System.getProperty("java.vm.version") and java -version probably being the simplest. A user shouldn’t have to resort to the command line. Instead they can just use the Finder to look in /Library/Receipts for an item named Java1.4.1.pkg.

The following sections discuss pertinent details you should be aware of to make sure that you are using the correct version of Java for your application. Since there are various ways in which you can deploy Java applications on Mac OS X, the sections are broken down based on your deployment vehicle.The following information applies only if the computer your application is being run on has both Java 1.4.1and Java 1.3.1 installed.

In this section:

Java Applications as Mac OS X Application Bundles
Java Web Start Applications
Double-clickable JAR Files
Command Line Applications
Java Applets
Native Applications That Invoke Java Through JNI

Java Applications as Mac OS X Application Bundles

When deploying a Java application on Mac OS X, you should wrap the Java application inside a native Mac OS X application bundle. This application bundle is just a directory with some information about the application itself and a native code stub to launch the Java application. You can construct an application bundle very easily with Jar Bundler which is available in /Developer/Tools. For users, the end result is a native application that is double-clickable in the Finder.

By default, existing Java applications that have been bundled as native applications run with the Java 1.3.1 VM. As such, they exhibit the same behavior as they did before installing Java 1.4.1. This behavior provides the cleanest user experience. From a user’s perspective, an application continues to work the same way it has always worked. This is important since, from the user’s perspective, the application is not necessarily a Java application, but rather a Mac OS X application.

You may determine that you want users to run your existing applications with Java 1.4.1 instead of Java 1.3.1, perhaps to take advantage of new features in the 1.4.1 version. In that case it is your responsibility to designate the appropriate version of Java for your application. You can do this by modifying the Info.plist file of the native application bundle.

For new applications, set the VM version in the Build Information pane of Jar Bundler, or the Pure Java-Specific pane in Project Builder’s target editor. If you are modifying an existing application, modify the JVMVersion property in the Info.plist file. This file is in the Contents folder of the application bundle. To view this file in the Finder, Control-click the application icon, then choose “Show Package Contents.”

The Info.plist file is an XML document, so you can modify it with any text editor. If there is not already a key for JVMVersion, you need to add one. This key should be in the Java dictionary. For example, the Java section of the Info.plist might look something like Listing 3-1.

Listing 3-1  Info.plist without JVMVersion property

<key>Java</key>

    <dict>

        <key>MainClass</key>

        <string>YourApplication</string>

        <key>ClassPath</key>

        <string>$JAVAROOT/YourApplication.jar</string>

    </dict>

At the same level as the existing key and string combination for the ClassPath, add in a key value of JVMVersion and a string value from Table 3-1 as appropriate. The resulting Info.plist should look something like that shown in Listing 3-2.

Listing 3-2  Info.plist with JVMVersion property

<key>Java</key>

    <dict>

        <key>MainClass</key>

        <string>YourApplication</string>

        <key>JVMVersion</key>

        <string>1.4+</string>

        <key>ClassPath</key>

        <string>$JAVAROOT/YourApplication.jar</string>

    </dict>

Some older applications may have an MRJApp.properties file instead of an Info.plist file. For these applications, add the following line with value set to an appropriate value from Table 3-1: com.apple.mrj.application.JVMVersion=value.

Java Web Start Applications

Java Web Start applications follow the guidelines laid out for standard JNLP-based applications. Your JNLP file should specify a J2SE Version key. This key is evaluated to determine whether to run your application with Java 1.3.1 or Java 1.4.1. The values presented in Table 3-1 also apply to Java Web Start applications. For more information on Java Web Start, see the Developers Guide at http://java.sun.com/products/javawebstart/1.2/docs/developersguide.html.

If you do not specify a value for the j2seversion key, Java 1.3.1 is used by the application.

When a user runs the same Java Web Start application multiple times, Mac OS X provides the option of building a native application bundle around that application. With this release of Java 1.4.1 these application bundles always launch with Java 1.3.1 regardless of what the JNLP file says.

Double-clickable JAR Files

If a JAR file has a main class specified in its manifest file, a user can launch it just by double clicking the JAR file. Double-clickable JAR files are run with Java 1.4.1. If you need to run a JAR file with Java 1.3.1, you can either wrap it as a Mac OS X application bundle using Jar Bundler or you can launch it from the command line with /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Commands/java -jar YourJARFile.jar.

Command Line Applications

Running java from the command line runs Java 1.4.1. The Java commands in /usr/bin are linked to the most current version of Java tools on the system. In this release they are linked to commands in /System/Library/Frameworks/JavaVM.framework/Versions/1.4.1/Commands. If you need to run the Java 1.3.1 version of a command line Java tool, you may do so by explicitly calling the appropriate Java 1.3.1 command in /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Commands.

If you are building shell scripts for distribution to customers that link to a specific version of a Java command in /System/Library/Frameworks/JavaVM.framework you should consider wrapping your application as a Mac OS X application with Jar Bundler. Specifying a specific path in the operating system (other than /usr/bin) is not the most robust solution since changes to Mac OS X may render these paths obsolete and your application broken.

Java Applets

Java Applets cannot choose which version of Java they invoke. This choice is made instead by the browser. Microsoft’s Internet Explorer uses Java 1.3.1. Apple’s Safari uses Java 1.4.1. (Applet Launcher also uses Java 1.4.1.)

Native Applications That Invoke Java Through JNI

By default, if the first call into the JavaVM framework is JNI_CreateJavaVM where JNI_VERSION_1_2 specified, the Java 1.3.1 virtual machine (VM) is used. This is done to maintain backward compatibility with the Java 1.3.1 version of applications that may already be in use on the system. If you need to use the 1.4.1 VM and link against the 1.4.1 version of jni.h, pass JNI_VERSION_1_4 instead of JNI_VERSION_1_2. If you call JNI_GetDefaultJavaVMInitArgs before JNI_CreateJavaVM you will also get Java 1.4.1.

< Previous PageNext Page > Hide TOC