Closed ctrueden closed 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:
JAVA_HOME
pointing to an Apple JVM. As things stand, we violate the Principle of Least Astonishment, and users will probably complain that this doesn't work, especially on systems with both Apple 1.6 and Apple 1.5 available.JAVA_HOME
in ImageJ.cfg
as a launcher setting, and expose it in the ImageJ UI as an option (see also ticket #2037).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)
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.
@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.
The magic MacOSX code was not needed, after all...
@ctrueden could you test the current 'master', please? If it works, I want to release... first time to Sonatype!
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!
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.
@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.
@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...
Ah, forget that. I cannot really test Java3D in headless mode. Sorry for the noise. I'll prepare something real quick.
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?
@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).
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
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.
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.
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.
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!
@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
@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...
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.