http://imagej.273.s1.nabble.com/experience-with-Java-1-7x-and-ImageJ-tp5008612p5008613.html
I've not been active on either machine lately. I hope to move to 1.8 when
> 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>