Closed ctrueden closed 9 years ago
I think this issue will become increasingly important over time, as more and more people have newer OS X with newer Java, and do not want to create an Apple developer account (so that they can download and install Java 6) just to be able to run ImageJ.
Also: note that our cyber
server is a system affected by this bug: it runs Mavericks and does not have a Java 6 installation.
I guess the problem is that the old recommended way to use Java was to use Apple's non-standard -framework
option. We will have to be careful that we can still call Java 6 even without linking via the framework option but instead using the dylib version (which was the original way until Erwin Frise pointed out that Apple discouraged that way in the old days when they did not yet wage the war against Java).
This was fixed with the merge of #25, though it still needs testing. Once the new version has been tested a bit more, we'll upload it to the ImageJ update site, and close out this issue. See also this FAQ entry.
I was able to get this to work on a Yosemite system that has never seen Java 6. I used the imagej-launcher linked in the FAQ entry, moved it to /Applications/Fiji.app/Contents/MacOS/
and chmod
ed it to executable for all. I then renamed ImageJ-tiger
and symlinked imagej-launcher
to ImageJ-tiger
. I see that /Applications/Fiji.app/Contents/MacOS/Info.plist
has set Executable file
to ImageJ-tiger
, so the FAQ entry may need to be updated.
I did not need to play around with imagej-launcher-3.3.0.jar
, mentioned elsewhere on the mailing list. At least, not so far.
All of this on a fresh install of Fiji from http://jenkins.imagej.net/job/Stable-Fiji-MacOSX/lastSuccessfulBuild/artifact/fiji-macosx.dmg
@rsrock Thanks very much for the detailed feedback. Good point about ImageJ-tiger
—I forgot about that piece of the puzzle. We will probably need to discontinue that sham of support for such old OS X versions, anyway.
the FAQ entry may need to be updated
Indeed, it's a wiki, so feel free to do it!
Wiki updated (now that I found my login info...)
@rsrock Thank you very much!
It pains me to report that on my system, the new ImageJ-macosx
launcher indefinitely continues to consume 100% CPU after ImageJ finishes launching. (I didn't notice at first because it's a multi-core system.) We definitely won't be able to update the ImageJ launcher until that problem is resolved.
Feedback from others about whether they experience the same CPU drain would be appreciated.
We definitely won't be able to update the ImageJ launcher until that problem is resolved.
If you provide me with a way to reproduce, I will fix it.
Just to let you know my experience: Fresh installation of OS X 10.10.2 on a partition of main hard drive (latest continuous release from fiji.sc/Downloads, after applying the new launcher). Did not yet see the 100% CPU usage. Are there any specific steps to trigger it?
However, it seems that the installation procedure in Yosemite will be very cumbersome to new users:
"To view this web content, you need to install the Java Runtime Environment. Click “More Info…” to visit the website for the Java Runtime Environment."
- Download and ran the installer from the proposed URL
- The installer confirms that Java is successfully installed. However, the same message saying a JRE is required, appears repeatedly on every attempt to start Fiji.
It turns out that the installed JRE (jre-8u40) gets installed in an awkward place:
/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java
In the terminal when I run which java
, I get /usr/bin/java
which points to /System/Library/Frameworks/JavaVM.framework/
which refers to the Java 6 installation, that got installed the first time Fiji was opened without the new launcher.
It is only after trying to run java from the Terminal e.g., java -version
, that I get a more appropriate message:
"To use the “java” command-line tool you need to install a JDK. Click “More Info…” to visit the website ...
It finally worked after running the new installer (now /usr/bin/java
points to a java 8 installation in /System/Library/Frameworks/JavaVM.framework/
) even if the Java Preference Pane in System Preferences only reports the path to the funky JRE installation in /Library/Internet/Plugins/
I guess for fresh installations, the user will have to do one of the following, before giving up in frustration:
/Library/Internet\ Plug-Ins/
to somewhere visiblebrew install caskroom/cask/brew-cask; brew cask install java
@dscho wrote:
If you provide me with a way to reproduce
I wish I knew how. Maybe as an alternative... any hints on how to best debug it on my own machine? I am pretty clueless about native code. Do you recommend any better way to profile the code than simply adding print statements?
This is how I would debug it: I would start the launcher in gdb
(if only lldb
is available, I use this to help me). Once the 100% CPU stage is reached, I would hit Ctrl+C in the debugger to suspend the program, then inspect info thread
for likely culprits, switch to the threads with thread <n>
and then look at the stacktrace with bt
.
If you provide me with a way to reproduce
I wish I knew how.
ssh
.
Finally made time to revisit this issue. Thanks @dscho for the reminder about gdb
/lldb
. Of course, we already created the DEBUG.md
with instructions along these lines—I had just forgotten about it.
Anyway, I can no longer reproduce the 100% CPU issue. I will keep testing various configurations and systems. I did find a different problem with libjvm.dylib
not being found when using Apple Java 6; there is code to deal with it but it's not working on my system for some reason.
Are you sure that it is libjvm.dylib
? The code you referenced (you might want to hit y
to make it robust against future changes in master: https://github.com/imagej/imagej-launcher/blob/893d9ca31dba53c5ef5cd7d84c8f230474b2aa18/src/main/c/platform.c#L416-L420) seems to suggest that libserver.dylib
is the target for 64-bit setups, while libjvm.dylib
is the target for 32-bit ones.
Downloading the updated launcher did NOT work for me.
What worked: using homebrew to install java, as recommended by dscho! Thank you.
brew install caskroom/cask/brew-cask; brew cask install java
Why not recommend this, and recommend brew installation of fiji as well?
@ewallace Good idea! I filed an issue for it: https://github.com/imagej/imagej/issues/124
Unfortunately, I don't think Homebrew could fully replace a downloadable .dmg file, given most OS X users' standard workflows. And it would be nontrivial to create—it is unlikely any of the primary developers will have time to do so within the next few months. But as always, PRs (in this case, maybe a new repository) are very welcome!
@ctrueden thank you. The number of times the answer to my cryptic installation problems has been "use homebrew" is ever growing...
Downloading the updated launcher did NOT work for me.
Please note that this information is too scarce to inform me as to what is happening. You would need to say exactly what you downloaded (link!), what you did to start it (command-line? double-click? Finder?), and then what you saw, and then what you expected to see. The better your bug report, the better your chances of getting high quality help by the original author of the piece of software you are criticizing.
The better your bug report, the better your chances of getting high quality help
Indeed. @ewallace, see http://imagej.net/Bug_reporting_best_practices for a guide.
Indeed the hacked application did not work for me either, but the installation of Java via HomeBrew did. I wouldn't say that all OSX users are too lazy to discover the CLI, but I see your point. If you put up instructions on how to install HomeBrew and Java, I think it would work. It was pretty easy to copy and paste the commands and approve the sudo a few times.
The updated launcher has been in the wild and working for a couple of months now.
Even if Java 7 or 8 is installed, and even if that version is requested via the
--java-home
flag and/orJAVA_HOME
environment variable, the ImageJ launcher still prompts to install Java 6. If possible, we should avoid doing that.Maybe this is caused by the executable linking to the Java 6 shared library? If so, we might need to do some more shenanigans with multiple executables a la
ImageJ-macosx
andImageJ-tiger
, to avoid invoking a tainted executable unless Java 6 is actually needed...