experience with Java 1.7x and ImageJ

[Walter O'Dell PhD]

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

[Robert Lockwood]

My iMac has 1.7 but my MacAir apparently automatically updated to 1.8:

Roberts-MacBook-Air:~ nate$ javac -version

javac 1.8.0_05

Roberts-MacBook-Air:~ nate$ java -version

java version "1.8.0_05"

Java(TM) SE Runtime Environment (build 1.8.0_05-b13)

Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)


I've not been active on either machine lately.  I hope to move to 1.8 when
my new work computer arrives and I install Ubuntu 14.04.

Thanks for the discussion.


On Mon, Jul 7, 2014 at 3:58 PM, Walter O'Dell <[hidden email]> wrote:

> 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
>

--
When I was 12 I thought I would live forever.
So far, so good.

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

[dscho]

Hi Walter,

thank you for the detailed account!

Just quickly (because I have little time this week) to clarify the
Fiji/ImageJ2 situation:

On Mon, 7 Jul 2014, Walter O'Dell wrote:

> 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.

You probably know that we do not use the application bundler and after
going through the ordeal you described, you also know why.

We already have some method to run with a different Java version:

http://fiji.sc/FAQ#How_do_I_launch_ImageJ_with_a_different_version_of_Java.3F

However, in my hands, Java 7 was not as stable on MacOSX. Besides, I have
a MacBook that is simply too small for MacOSX later than 10.6, and in
particular in the academic environment, I figure I am not alone. So Java 7
is simply out of reach.

I would be delighted, of course, if you helped us improve the ImageJ.app
and Fiji.app bundles!

Ciao,
Johannes

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

[dscho]

Hi Walter,

On Tue, 8 Jul 2014, Walter O'Dell wrote:

> thanks for your info. In regards to the bundle, yesterday I forwarded to
> Wayne the bundle that I ultimately used successfully, after receiving
> this email from him.
>
> In case you find it helpful also, I’m happy to send ot on to you. If you
> need me to work on a version for Fiji I can try that (after today’s
> BRA-GER game of course), but I don’t have much experience with Fiji.

As I pointed out, we cannot simply force users to upgrade their operating
system. So I doubt that we can easily make use of the application bundler
you used. It might work for you, but we have a larger obligation than
that... :-(

Besides, we have quite a bit of code added to offer
backwards-compatibility, including the ability to specify the amount of
RAM to reserve without having to edit Contents/Info.plist, and including
support to use the exact same bundle for 32-bit and for 64-bit.

Ciao,
Johannes

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

[kacollins]

Walter,
     Thank you for your thorough research of this issue and for taking the time to share what you have learned with the rest of us. This is very useful information.

Karen

[kacollins]

Hi Johannes,
I am using a Mac running OS X Yosemite (10.10) with Java jdk 1.7.0_71 installed. I would like to run Fiji or ImageJ using the command provided at the link in the previous post. When I do that, with the command altered for the jdk version and specifics of the installation path, I still get the irritating message "To open "Fiji" you need to install the legacy Java SE 6 runtime."

Is the command line method known to work properly with Yosemite, or is there something else I can try?

Karen

[John Minter]

Hi Karen,

Check out

http://apple.stackexchange.com/questions/153584/install-java-jre-6-next-to-jre-7-on-os-x-10-10-yosemite

I am running Apple's 1.6.0_65 on Yosemite 10.10.1 with Fiji/ImageJ. It gets
installed in /System/Library/Java/JavaVirtualMachines.

I also have jdk1.7.0_71.jdk and jdk1.8.0_25.jdk in
/Library/Java/JavaVirtualMachines.

On Fri, Nov 28, 2014 at 1:52 PM, kacollins <[hidden email]>
wrote:

> Hi Johannes,
> I am using a Mac running OS X Yosemite (10.10) with Java jdk 1.7.0_71
> installed. I would like to run Fiji or ImageJ using the command provided at
> the link in the previous post. When I do that, with the command altered for
> the jdk version and specifics of the installation path, I still get the
> irritating message "To open "Fiji" you need to install the legacy Java SE 6
> runtime."
>
> Is the command line method known to work properly with Yosemite, or is
> there
> something else I can try?
>
> Karen
>
>
>
> --
> View this message in context:
> http://imagej.1557.x6.nabble.com/experience-with-Java-1-7x-and-ImageJ-tp5008612p5010680.html
> Sent from the ImageJ mailing list archive at Nabble.com.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

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