Updated ImageJ Launcher + Java Bundles

Hi everyone!

After identifying and fixing a stubborn Windows issue with the new launcher, we decided it was time for another go at a release!

If you run Help > Update... you will now get the 6.0.1 launcher. The primary motivation for this release has been to broaden the launcher’s compatibility with different Java vendors and version. So, while not very exciting for existing installations, this means that the Fiji bundles now ship with Azul Java 8 JDK+FX, allowing for JavaFX use out of the box.

As always, if you run into any problems or notice any oddities, please let us know. Thank you for your time and feedback.

8 Likes

Hello Mark -

An auto-update to my Fiji / ImageJ gave me a broken launcher.

Running ./ImageJ-linux64 from a terminal in the Fiji.app
directory gives the following error:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007feca98e1009, pid=4000, tid=4000
#
# JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-2016-04-14-195246.buildd.src)
# Java VM: OpenJDK 64-Bit Server VM (9-internal+0-2016-04-14-195246.buildd.src, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libjava.so+0x1d009]  JNU_GetEnv+0x19
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/user/Documents/fijifun/fiji_install/fiji_plugins/Fiji.app/core.4000)
#
# An error report file with more information is saved as:
# /home/user/Documents/fijifun/fiji_install/fiji_plugins/Fiji.app/hs_err_pid4000.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted (core dumped)

Here is the hs_err file:

hs_err_pid4000.log.txt (79.9 KB)

If I instead run ./ImageJ-linux64.old, Fiji launches fine (but
does give me some previously-seen
net.imagej.patcher.CodeHacker.replaceCallInMethod()
errors).

This is running 1.53g5 on ubuntu 16.04 LTS.

Thanks, mm

@hinerm
On Win10 Pro the new laucher starts as expected (with Java 1.8) only with a modfied Imagej.cfg file.
As long as the line jre\bin\javaw.exe is included in the cfg file FIJI is started with the system Java (12.0.1 in my case).

Another change is that when FIJI is started with the new laucher javaw.exe is calling home (apparently to anywhere else than tp the FIJI server) during FIJI update.
Instead of ImageJ-win64.exe the javaw.exe has to be allowed in the firewall outbound rules.
Was this intended?

1 Like

Hi Mark, I think the update unfortunately broke my Fiji running on a Windows Server 2019 Datacenter.
I just get this message:
Error

The system has JRE 1.8.0_271 x86

Starting ImageJ-win64.old.exe works fine. Let me know if and how to debug.
Daan

Indeed, the CodeHacker-related errors are expected, as long as you run an ij.jar newer than the one shipped with Fiji (which currently ships 1.53c). The reason for this are recent changes to ImageJ1 which are not headless-compatible, and have to be accounted for in ij1-patcher in order to be able to run in a headless environment.

Usage in a non-headless (i.e. GUI) environment should be unaffected though.

(This is unrelated to the launcher issues discussed here, sorry for the off-topic post.)

2 Likes

after update in windows10, ImageJ GUI doesn’t start anymore…
no error thrown.

The No JRE Fiji had been broken in Debian 10 (and most recent Debian based distros such as Ubuntu) for a while now. It was still broken earlier this week, but today’s version works fine. By the way, you mention version 6.0.1, but I actually see jars/imagej-launcher-6.0.0.jar.

For what is worth, the reason it had been failing before is that it failed to find libjvm.so which is at /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so

1 Like

@phaub I am confused. If you remove the ImageJ.cfg, which Java is picked up by the new launcher? Your system (12) or bundled (8)?

I also opened an issue to discuss ImageJ.cfg behavior.

This wasn’t an intentional change. Do you think it warrants an issue to discuss?

Hi @daanb88

Thank you for the report! Interesting, that is a 32-bit JRE. Is there anything in your Fiji.app/jre or Fiji.app/java/ directories?

What happens when:

  1. You run ImageJ-win32.exe?
  2. Rename ImageJ-win64.old.exe to debug.exe and run it? Can you paste or attach the output?

@emartini

  1. Can you rename ImageJ-win64.exe to debug.exe and paste/attach the output?
  2. Is this Windows 10 Pro or Home?

That is exactly what we fixed in the new launcher, so hooray! Thanks @carandraug!

Yes sorry. The 6.0.1 change only affected the windows launcher; mac, linux and the java code are from 6.0.0. It looks like there will likely be a 6.0.2 to address aforementioned issues, so in the future I’ll just upload all artifacts from the same version for consistency. Thanks for pointing that out!

1 Like

Hi Mark,

This sounds great! I updated to the new launcher without any problem on macosx.

I also downloaded a new version of Fiji using your link. It came with adoptopenjdk-8.jdk in the java folder. But this does not appear to contain javafx. I searched for some javafx jars using the Find jar command and they were not found. So is the plan to troubleshoot issues with the launcher and then later add the Azul Java8 JDK+FX? Or did I somehow get directed to the wrong download site?

Thanks for your efforts on improving the launcher!

2 Likes

@karlduderstadt thanks Karl!

Oh no! The Windows bundle has the Azul JDK+FX bundle so it looks like there was a mixup on Mac. I will double check all the bundles and get them updated. The bundles that should have Azul JDK+FX are: Win64, Linux64, MacOS. Thanks for pointing that out!

Edit: all bundles are built by Fiji-builds which is supposed to pull the platform bundles from downloads.imagej.net/java. These are all currently Azul JDK+FX bundles so it looks like I’ll have to debug deeper into the bundle process to figure out what went wrong.

@karlduderstadt In the mean time you can get the intended Java bundle from imagej.net or Azul directly

3 Likes

In my /java/ is JRE 64 bit:
JAVA_VERSION=“1.8.0_172”
OS_NAME=“Windows”
OS_VERSION=“5.2”
OS_ARCH=“amd64”

There was no 32 bit imageJ, but one I downloaded and copied in my Fiji directory started just fine.

debug.txt (758.3 KB)

I’m just a user of the server, but I’ll ask my admin why a 32bit JRE is installed:-)

1 Like

Starting with the new launcher and
with Image.cfg with line jre\bin\javaw.exe => system java 12.0.1
with Image.cfg without line jre\bin\javaw.exe => java 1.8.0_172
without Image.cfg => java 1.8.0_172

1 Like

I’m not sure.
Some FIJI users have to request a Firewall clearance at their IT administration. I’m not sure how they will handle this.

1 Like

Hi Mark,

I cannot start Fiji after the latest update

152722

Fiji is on a Windows10 Enterprise machine (64-bit OS). The system has JRE 1.8.0_271.
I renamed ImageJ-win64.exe to debug.exe and run it. I have attached the output
debugOutput.txt (607.0 KB)

@phaub I think that’s a great point and is totally worth further discussion and tracking. However, as a test I just booted up an ImageJ 1.x and in my firewall notice it seems like it’s javaw.exe making the request:

Oddly, I couldn’t get a firewall request to trigger from either ImageJ-win64.exe launcher in Fiji, despite clearing its entry in the windows defender firewall.

I made an issue to explore and discuss further.

That’s interesting. Since there are a few ways to download launchers, I wanted to mention you can also run Help > Update... and in the Advanced mode dialog, View files of the 'Java-8' Update Site and get it directly from there:

@davidC Thank you for the debug.exe output! I noticed this line:

Using JRE from ImageJ.cfg: C:\Local\Fiji.app/jre

indicating it has an ImageJ 1.x .cfg file.

@daanb88 I think your debug.exe output may have been cut off? You can also launch it as ImageJ-win64.exe --debug from a command prompt (and ImageJ-win64.exe --debug --console to print the output to the same console).

In any case, I am wondering if you also have an ImageJ.cfg?

@daanb88 @davidC Could you try removing the ImageJ.cfg or removing the Java path specification from the ImageJ.cfg? (i.e. any line like C:\Local\Fiji.app/jre or jre\bin\javaw.exe) Then try launching the new ImageJ-win64.exe again and let me know how it goes.

Thank you so much!

2 Likes

Hi Mark,
I’m also getting an error after this update. Fiji crashes when I try to open the 3D Viewer. I’m running Fiji on Ubuntu 20.04.1

Thanks!
Ezra

Here is the error log hs_err_pid4287.log.txt (251.3 KB)

1 Like

@hinerm deleting the line jre\bin\javaw.exe from ImageJ.cfg did the trick. Fiji is now starting and seems to run fine. Thanks!

3 Likes

Hi @EzraL! Thank you for the report. I assume you are launching with ImageJ-linux64? Do you have a ImageJ-linux64.old you can compare with? I would like to know if the Java version changes between the two launchers.

Also:

  • Have you used 3D Viewer recently, or did you just update to 4.0.3? (I assume you have Fiji.app/plugins/3D_Viewer-4.0.3.jar)
  • Have you made any changes to your ~/ImageJ_3D_Viewer.props?

Hi Mark,
Yes. When I open with ImageJ-linux64 I run into this problem with the 3D viewer. Just checked and when I open with ImageJ-linux64.old I have no problems. Happy to check whether the java changes versions when I launch these two apps. Just let me know what would be helpful. When I check using ‘About ImageJ’ I get the following:
ImageJ-linux64 is running Java 1.8.0_272
ImageJ-linux64.old is running Java 1.8.0_172

I opened ImageJ-linux64 using the terminal and get the following null pointer error copied into this file: ImageJ.error.txt (2.1 KB)

Thanks so much for your help and hard work! For now I’m just using the ImageJ.old

2 Likes

Oh, I believe that’s actually an unrelated(?) issue reported (with a workaround) here. It’s on my radar and actually next on my list to investigate after the launcher.

Perfect! So it looks like the 3D Viewer may have an incompatibility with the 1.8.0_272 Java. I opened an issue to investigate further. Until that gets resolved I agree that running with 1.8.0_172 via the old launcher is best.

Could you check one more thing: run ImageJ-linux64 and ImageJ-linux64.old in debug mode and paste a text doc with the console output? I just want to verify which Java version should be used…

1 Like