search

imagej / imagej-launcher

The ImageJ native launcher
https://imagej.net/learn/launcher
BSD 2-Clause "Simplified" License
21 stars 23 forks source link

Improve Java version detection on OS X #1

Closed ctrueden closed 10 years ago

ctrueden commented 10 years ago

In particular, this branch improves the behavior for OS X 10.9 (and very likely 10.8, too).

This branch fixes a problem where JAVA_HOME (via --java-home or otherwise) on OS X had absolutely no effect. Now, setting that variable is respected as long as it points to a non-Apple JVM (e.g., OpenJDK 7).

It also preserves the behavior of defaulting to Apple's Java: first 1.6, then 1.5, and finally resorting to the default installed version if any. Only when JAVA_HOME is given, or no Apple Java is present at all, will a non-Apple Java such as OpenJDK 7 be used.

Lastly, it fixes several logic errors in various methods of the OS X case logic.

ctrueden commented 10 years ago

Note that this branch is not quite ready to be merged: there is one remaining WIP commit which I briefly discussed with @dscho, and which needs to be tweaked somehow before the branch is ready for prime time. But other than that, I am very happy with things.

Future directions:

ctrueden commented 10 years ago

Trying to launch 3D Viewer on OS X Mavericks:

From osx-java-versions:

Exception in thread "J3D-Renderer-1" java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/libjogl_awt.jnilib: Library not loaded: /System/Library/Frameworks/JavaVM.framework/Libraries/libjawt.dylib Referenced from: /Library/Java/Extensions/libjogl_awt.jnilib Reason: image not found

From master:

Exception in thread "J3D-Renderer-1" java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/libjogl_awt.jnilib: Library not loaded: /System/Library/Frameworks/JavaVM.framework/Libraries/libjawt.dylib Referenced from: /Library/Java/Extensions/libjogl_awt.jnilib Reason: image not found

$ ls -l /System/Library/Frameworks/JavaVM.framework
total 32
lrwxr-xr-x  1 root  wheel   27 Oct 22 15:35 Frameworks@ -> Versions/Current/Frameworks
lrwxr-xr-x  1 root  wheel   24 Oct 25 00:35 Headers@ -> Versions/Current/Headers
lrwxr-xr-x  1 root  wheel   23 Oct 22 15:35 JavaVM@ -> Versions/Current/JavaVM
lrwxr-xr-x  1 root  wheel   26 Oct 22 15:35 Resources@ -> Versions/Current/Resources
drwxr-xr-x  5 root  wheel  170 Nov 13 14:42 Versions/
-rw-r--r--  1 root  wheel  104 Oct 22 15:31 module.map
$ ls -l /Library/Java/Extensions
total 24992
-rwxrwxr-x  1 curtis  admin    18416 Aug 19  2009 gluegen-rt.jar*
-rwxrwxr-x  1 curtis  admin  2957997 Aug 19  2009 j3dcore.jar*
-rwxrwxr-x  1 curtis  admin  1704635 Aug 19  2009 j3dutils.jar*
-rwxrwxr-x  1 curtis  admin    49525 Aug 19  2009 jhdf5.jar*
-rwxrwxr-x  1 curtis  admin    46046 Aug 19  2009 jhdf5obj.jar*
-rwxrwxr-x  1 curtis  admin    17526 Aug 19  2009 jhdfobj.jar*
-rwxrwxr-x  1 curtis  admin  1126370 Aug 19  2009 jogl.jar*
-rwxrwxr-x  1 curtis  admin    49800 Aug 19  2009 libgluegen-rt.jnilib*
-rwxrwxr-x  1 curtis  admin  3110396 Aug 19  2009 libjhdf5.jnilib*
-rwxrwxr-x  1 curtis  admin  2838744 Aug 19  2009 libjogl.jnilib*
-rwxrwxr-x  1 curtis  admin    50312 Aug 19  2009 libjogl_awt.jnilib*
-rwxrwxr-x  1 curtis  admin   470352 Aug 19  2009 libjogl_cg.jnilib*
lrwxr-xr-x  1 root    wheel       40 May 20  2013 libsvnjavahl-1.jnilib@ -> /opt/subversion/lib/libsvnjavahl-1.dylib
-rwxrwxr-x  1 curtis  admin   318956 Aug 19  2009 vecmath.jar*
$ otool -L /Library/Java/Extensions/libjogl.jnilib
/Library/Java/Extensions/libjogl.jnilib:
    libjogl.dylib (compatibility version 0.0.0, current version 0.0.0)
    /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
    /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.10.0)
    /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.27.0)
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0)
    /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.15.0)
$ otool -L /Library/Java/Extensions/libjogl_awt.jnilib
/Library/Java/Extensions/libjogl_awt.jnilib:
    libjogl_awt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
    /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/JavaVM.framework/Libraries/libjawt.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
ctrueden commented 10 years ago

Also:

-Djava.library.path=/Users/curtis/code/imagej/imagej-launcher/lib/macosx:/Users/curtis/code/imagej/imagej-launcher/mm/macosx

But that needs to match ij-dir instead, right? Also, does /Library/Java/Extensions need to be in the library path explicitly now? @dscho, I am willing to keep hammering on this but I suspect you have a more well-rounded insight into how you want the launcher to work here.

ctrueden commented 10 years ago

@dscho and I discussed, and the plan is to overhaul the way Fiji handles ext libraries. We are holding off on this branch until probably after the holidays, when the issue can be fully addressed.

dscho commented 10 years ago

The magic MacOSX code was not needed, after all...

dscho commented 10 years ago

@ctrueden could you test the current 'master', please? If it works, I want to release... first time to Sonatype!

ctrueden commented 10 years ago

Thanks very much for merging!

The current master works just fine on my system (though I see that you left ef5d05556bef579bbaa4be8a44bde85c83394aa2 as-is with the 'WIP' prefix). Launching with no args gives me Apple Java 6 (since I have it installed), and with --java-home set to my Oracle JDK 7 installation works too.

The 3D Viewer still does not work, however:

Exception in thread "J3D-Renderer-1" java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/libjogl_awt.jnilib: dlopen(/Library/Java/Extensions/libjogl_awt.jnilib, 1): Library not loaded: /System/Library/Frameworks/JavaVM.framework/Libraries/libjawt.dylib
  Referenced from: /Library/Java/Extensions/libjogl_awt.jnilib
  Reason: image not found

Because my /System/Library/Frameworks/JavaVM.framework no longer has a Libraries directory at all. When I installed Mavericks it took the liberty of cleaning it out, leaving me with invalid libjogl libraries I guess.

Firstly, I wonder why it was trying to load /Library/Java/Extensions/libjogl_awt.jnilib at all, when (I thought) Fiji preferred /Applications/Fiji.app/java/macosx-java3d/Home/lib/ext/libjogl_awt.jnilib (otherwise, why do we bother bundling that?).

Secondly, even if it did use the bundled libjogl_awt.jnilib, I expect we would end up with the same problem:

$ otool -L /Applications/Science/Fiji.app/java/macosx-java3d/Home/lib/ext/libjogl_awt.jnilib
/Applications/Science/Fiji.app/java/macosx-java3d/Home/lib/ext/libjogl_awt.jnilib:
    libjogl_awt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
    /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/JavaVM.framework/Libraries/libjawt.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)

Anyway, we can deal with all that JOGL stuff separately, since it is a different issue than the Java version detection. Thanks again!

dscho commented 10 years ago

Hmpf. I tested it here (on the Snow Leopard laptop you gave me) and it worked fine. Maybe we can pair-program on this today for an hour or so? We should be able to flesh things out.

ctrueden commented 10 years ago

@dscho: Many of the problems addressed by this branch are specific to 10.8 and 10.9. Testing on 10.6 would not have been sufficient.

Also, note that @apal4's machine also runs OS X 10.9 and does not have this problem with the 3D Viewer. So it may be something odd about system (perhaps because I reinstalled Java 6). But regardless, I think the information above demonstrates that something is not quite correct with the Launcher.

I would love to pair program on the issue, but perhaps better to schedule it for next week because my plate is currently overflowing.

dscho commented 10 years ago

@ctrueden I just tried on 10.8 and it works there. Could you give me ssh access to your box? Then I can figure it out on my own...

dscho commented 10 years ago

Ah, forget that. I cannot really test Java3D in headless mode. Sorry for the noise. I'll prepare something real quick.

emii commented 10 years ago

Hi, I just installed FIJI on OSX 10.9 which provides JDK1.8 however while launching FIJI it doesn't detect this version and asks me automatically to download JDK1.6. I tried providing either --java-home or exporting JAVA_HOME the above mentioned directory. This didn't solved my problem, any other workaround available?

dscho commented 10 years ago

@emii could you go to the command line and issue the following commands (do not copy & paste blindly but adjust as necessary):

cd /path/to/Fiji.app/
cp Contents/MacOS/ImageJ-macosx debug
./debug --java-home=/my/java/home/ 2>&1 | tee log.txt

This will produce tons of output and also write it to a file called log.txt. Hopefully inspecting it will give you a good idea what is going wrong. If not, please paste it here (preferably just the parts relevant to this issue).

emii commented 10 years ago

Hi @dscho , thanks for the prompt reply, I tried this, however the output was just: No Java runtime present, requesting install. and then a pop-up appeared asking me to download the JRE 6. This is however weird since entering java -version returns

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)

which means that at least java is actually present in the system. The question is whether I should or should not install an older version of JRE to make FIJI work since I already have the latest installed.

ps. I also tried with the export JAVA_HOME=/path/to/my/java/home ps 2. the FIJI version is the continuous release (no JRE) from http://fiji.sc

dscho commented 10 years ago

I also tried with the export JAVA_HOME=/path/to/my/java/home

I actually hoped for the output of that run, because running without JAVA_HOME will default to Java 6 because Java 7 was not really stable on MacOSX for a long time; I ran into so much trouble that I simply hardcoded Java 6 which works fine.

Note that you have to set the correct JAVA_HOME.

And if you do not even see the Detected Fiji message, you're not running via debug. This is an example output on my machine, with an incorrect JAVA_HOME:

$ JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home/ ./debugsysctl says os_release is 10.8.0
Detected Fiji
Available RAM: 3119MB, using 3/4 of that: 2340MB
JRE not found in '/Applications/Fiji.app/jre'
Ignoring Apple Framework java executable: '/System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java'
Ignoring JAVA_HOME (does not exist): /System/Library/Frameworks/JavaVM.framework/Home//lib/server/libjvm.dylib
[...]

Since I am on Snow Leopard and Apple made it impossible to run Java 7 on that operating system (early versions of the OpenJDK support for MacOSX built really fine on Snow Leopard, they actively broke that support), I cannot give you more help (but you really might want to dig a little deeper yourself, for example really running this thing from the command-line as I suggested and if it does not show any output, try harder). I just suspect that the correct setting for you will be something like /System/Library/Java//JavaVirtualMachines/1.7.0.jdk/. I say like to give you a strong hint that this is not intended as a "copy&paste without thinking" solution. Sorry.

ctrueden commented 10 years ago

The correct path is probably:

/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home

And that's a "copy&paste without thinking" promise!

You might also find my java-info script helpful to learn more about your Java installations.

ctrueden commented 10 years ago

FWIW, I tested with both:

JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home /Applications/Fiji.app/Contents/MacOS/ImageJ-macosx

and

/Applications/Fiji.app/Contents/MacOS/ImageJ-macosx --java-home /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home

and both of them launch Fiji with Java 1.8 on my Mavericks system.

emii commented 10 years ago

Hi both,

It turned out that the only way I found to run FIJI/IJ2 (either release or debug mode) and afterwards changing the _JAVAHOME was to download and install Java 6 provided either by following the pop-up message that appeared by simply running FIJI (No Java runtime present, requesting install.) or by apple support.

After this I could:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/
/Applications/Fiji.app/Contents/MacOS/ImageJ-macosx

and open FIJI

By running debug as suggested above: ./debug 2>&1 | tee log.txt:

sysctl says os_release is 13.2.0
Detected Fiji
Available RAM: 6677MB, using 3/4 of that: 5008MB
JRE not found in '/Applications/Fiji.app/jre'
JAVA_HOME contains a JRE: '/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre'
Using JAVA_HOME /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre
Work around attempt at MacOSX world domination:     /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jli/libjli.dylib
Opening Java library /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/server/libjvm.dylib
Jun 20 15:13:55 mac-derenzis17.local debug[7679] <Error>: The function `CGContextErase' is obsolete and will be removed in an upcoming update. Unfortunately, this application, or a library it uses, is using this obsolete function, and is thereby contributing to an overall degradation of system performance.
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release
Adding option: -Djava.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home
[...]

Actually I just wanted to save the task of downloading Java 6, but at the end I had to, either way and as far as I understood there is no advantage in using a newer version, or is there?

Thanks!

ctrueden commented 10 years ago

@emil I agree that it is undesirable to force installation of Java 6, even if Java 7 or 8 is already installed and even passed via the --java-home setting. I have filed a new issue to track that problem: https://github.com/imagej/imagej-launcher/issues/16

ctrueden commented 10 years ago

@emil As for whether there is an advantage to running a newer version: at this point I think it might be better to use Java 7, since there are several critical Java 6 bugs fixed in Java 7. We had many Fiji crashes on the bundled version of Java 6 when stitching large datasets, which did not occur with Java 7. We haven't tested much with Java 8 yet, though...