Updated ImageJ Launcher + Java Bundles

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

The system has JRE 1.8.0_271 x86

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

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.)


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?


  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!


@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


In my /java/ is JRE 64 bit:

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


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!


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


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!


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.


  • 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


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

Sounds good. Let me know if these are what you wanted. Thanks.

ImageJ-linux64.stdout.txt (808.8 KB)
ImageJ-linux64.old.stdout.txt (779.4 KB)

1 Like

Yes, that’s done it! :partying_face: Thanks for your help Mark.
Unfortunately the log in the console seems to be missing the first few lines, don’t know what’s causing that. Is there a log file saved somewhere - i copied it directly from the console?

Thanks for this tip as well!


Yes perfect! I found the problem (a skew in naming where the bundled Java goes) and will fix it with the next launcher patch.

It could also just be that the old launcher formatted its debug output differently, and didn’t debug as much information. If we identify it as an issue with the new launcher we can look into it more.

For now don’t worry about it - we got the info we needed and thank you for your help!!

In the next launcher patch we’ll find a more graceful way to handle existing ImageJ.cfg files.

1 Like