experience with Java 1.7x and ImageJ

Posted by Walter O'Dell PhD on Jul 07, 2014; 10:58pm
URL: http://imagej.273.s1.nabble.com/experience-with-Java-1-7x-and-ImageJ-tp5008612.html

greetings,

forewarning: below is a lot of gory details of getting ImageJ running with Java 1.7x on a Mac. If this is not of interest to you then you can hit the delete button now.

Summary: Apple created it’s own Java and application bundler that used unique Info.plist keywords, but Apple stopped doing so with Java 1.6x. Currently if you need new Java versions you’ll have to do much of the work yourself to compile ImageJ and create the bundle. Unfortunately Java 1.7 and higher will not run on machines running Mac OS X10.6 and lower, so for compatibility you’d need to stick with Apple’s Java 1.6.

My version of ImageJ (based on ImageJ 1.43, running on Mac 10.9) was plagued with repeated crashes that had something to do with moving, resizing and/or accessing image windows. It crashed such that it was not possible to debug the code to find the exact location in the code where it crashed, and it crashed at random places in the program. About every third run would crash like this. A google search implicated java 1.6 as a possible culprit, so I went about installing and running java 1.7.  Jumping to the end of my story, with Java 1.7.0_60 I have had none of the windows-related crashes that plagued my program previously.

Along the way I learned a few important things about Macs and Java.
1. through Java 1.6, Apple created it’s own version of Java but they stopped with that version.

2. my Mac does automatic updates of most programs, including Java, so my Mac had already Orcacle’s Java JRE 1.7x. Most web pages and programs that run Java on my machine already run with this Java 1.7, however when running through a terminal window or when using Xcode to compile ImageJ, the machine uses the latest developer version of Java, which was Apple’s Java 1.6x.  If you open a terminal window you can type ‘Java - version’ to see which developer version you have. This is because Mac updates only the JRE, not the JDK. To get everything running Java 1.7x you have to download and install the Oracle JDK 1.7x.  See http://docs.oracle.com/javase/7/docs/webnotes/install/mac/mac-jdk.html

3. With JDK 1.7.0_60 installed, after compiling my version of ImageJ with Xcode, Xcode would start up the program and it would run using Java 1.7x. However, when using the ImageJ desktop icon the program would not start, with an error message to the effect that Java 1.6x is needed.

4. Back when Apple made their own Java, they also made their own program that created application bundles for each program.  Someone up in NIH ImageJ-land used this program to create the application bundle that associates the ImageJ desktop icon with the running of ImageJ. You can look at this application bundle by right-clicking over the desktop icon and selecting “Show in Finder”; inside Finder right-click over the ImageJ64.app and select “Show Package Contents”; and inside the package contents there is the Info.plist file; inside the Java subdirectory is ij.jar; and inside the MacOS subdirectory is the ‘JavaApplicationStub’.  The bundle invokes Java/ij.jar using MacOS/JavaApplicationStub and reads executable options in Info.plist.

5. For my lab, whenever I had an updated version of my ij.jar I would copy it into this Contents/Java/ folder.  For my own use though I edited the Info.plist file to point to my local ij.jar: ~home_dir/ImageJ/ij.jar.  This gets around the need to create a new application bundle every time ij.jar is updated. I also added an JVMOption tag in Info.plist that sets my maximum program executable memory to something appropriately large for my Mac’s 20G of RAM, using ‘-Xmx18000m’ in the field for the execution-time option.  ImageJ lets you set the memory allocations within the ‘Edit’->’Options’ menu item and stores the preferences in IJ.prefs, however Xcode does not see this.  I need also to point to my local plugins directory which is done with another JVMOption tag ‘-Dplugins.dir=~home_dir/ImageJ/plugins'

6. The application bundle runs JavaApplicationStub that was created using Apple’s bundler tool and Java1.6x and thus would not run the new ij.jar compiled using Java 1.7x. To achieve an appropriate application bundle, since Apple stopped providing their own tool, you need to use the tool provided by Oracle:
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html

Following their directions, I added code to the build.xml that is/was used to compile ImageJ and used ‘Ant’ in a terminal window to create the application bundle. It also turns out that Apple stopped including ‘Ant’ in the system so that had to be downloaded and installed from http://ant.apache.org/bindownload.cgi.
This creates an application bundle that is similar to the original one for ImageJ, but the actual executable is now named JavaAppLauncher rather than JavaApplicationStub.

7. Almost there. Along with their own version of Java 1.6 and own application bundler tool, Apple also used their own keys/tags within Info.plist that are different from those used by Oracle. Thus in the new application bundle I had to transpose the keys/tags from the original Info.plist into the new one. See
https://developer.apple.com/library/mac/documentation/java/Reference/Java_InfoplistRef/Articles/JavaDictionaryInfo.plistKeys.html

Of particular importance for me was that I previously pointed to my local ij.jar using the ‘ClassPath’ key/tag, and now I add a string tag to JVMOptions with contents ‘-cp’    (where ‘cp’ stands for class path) and then the next string tag under JVMOptions is the actual path to my ij.jar, e.g. ~home_dir/ImageJ/ij.jar
Fortunately the plugin.dir and memory settings tags are the same as before.

In summary, Apple created it’s own Java and application bundler that used unique Info.plist keywords, but Apple stopped doing so with Java 1.6x. Currently if you need new Java versions you’ll have to do much of the work yourself to create the bundle. Unfortunately Java 1.7 and higher will not run on machines running Mac OS X10.6 and lower, so for compatibility you’d need to stick with Apple’s Java 1.6.
Eventually this will all have to get worked out in the main ImageJ and/or Fiji bundles, but for me I have my work-around. I do not yet know how ij.jar based on java 1.7x will run on MS Windows-based PCs.


Walter O'Dell, PhD
Assistant Professor
Dept. Radiation Oncology
McKnight Brain Inst. Rm LG-177
PO Box 100385
UF Health Cancer Center
University of Florida
Gainesville, FL 32610
[hidden email]
352-273-9030
http://odell.radonc.med.ufl.edu




--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html