Running multiple instances of ImageJ with Java 8 enabled



I will see if I can reproduce this on my Windows VMs. Stay tuned.

Edit: I can definitely reproduce in my Windows 10 VM. I filed an issue here: imagej/imagej-legacy#143. Not fixed yet, though, unfortunately.


Thanks! I hope it’s an easy fix that can be resolved quickly. In the meantime I will try to find a combination of versions that can run multistackregistration macros, open all similar files and also works with correct 3D drift. The last one is just the latest updated version though, so that’s easy.


Is it possible somewhere to see the different updates of Fiji that have been released recently? Because I know that I at some point in the last weeks was able to both run the newest version of multistackregistration (which requires java8) AND run multiple instances of ImageJ. That’s how I could confirm that Kotas fix for multistackregistration worked.

Would be nice to find that version of ImageJ again since it takes me forever to run registrations on large datasets one at a time.


I think reconstructing the combinations of the various Fiji components from different update sites at a certain time point in the past will be tricky.

Didn’t you say your problem is caused by the Java-8 update site being enabled? Can’t you just disable it but still run with Java 8 and the newest version of MultiStackRegistration?


Thanks, worked fine. For some reason I thought I was java 8 itself that made it not work, but it was just the update sites that needed to be unchecked.


The code for managing multiple instances of ImageJ lives in the ImageJ Legacy component, here. A savvy developer could use git bisect to discern which commit broke things. This is probably what I will do to debug the issue, once I have time to investigate it.


I’m a bit surprised that I seem to be the only one running more than one instance of ImageJ simultaneously! Is it possible to estimate when this issue will be fixed? I guess the Fiji development is done in peoples spare time since it’s open source? Just a little curious since it’s really a competitive alternative (and sometimes the only alternative) to all the extremely expensive software suites for scientific image analysis.


The component which needs the bug-fix is called ImageJ Legacy. The original person who coded ImageJ Legacy’s “single instance” feature has left the project. The person who fixed the bugs in that feature after the original person left the project, has left the project. It is currently my job to maintain it. But it is also my job to develop and/or maintain over 200 other components. I will try to investigate it soon—I consider this a very serious bug—but there are many other competing priorities.


A lot on your plate… I see, thanks for the info!


I believe I have tracked down the cause of this problem. I am hoping to get some feedback from @Wayne on whether my analysis is correct. See this comment if interested in technical details.

Edit: @David I have committed a workaround, which you are welcome to test. Download imagej-legacy-0.23.1-SNAPSHOT.jar and put it in your ImageJ jars folder, deleting the old jars/imagej-legacy-0.23.0.jar. ImageJ should then start respecting the “Run single instance listener” option again.

Note that this bug-fix does not make the --allow-multiple CLI flag work again—that is still broken. But it should at least be possible now to perform your analyses again.


Tested it, and it works perfectly. Can run multiple instances again. I guess you can add it to the uh… version that gets uploaded as the download package on the download page? I have no idea about how software development is organized (maybe you can tell…).



I uploaded the fix. The --allow-multiple flag is still not respected, but the “Use single instance listener” option should work again now. As with all fixes these days, you will need the Java-8 update site enabled to receive the fix.


The latest ImageJ daily build (1.51g19) fixes bugs that caused the “Run single instance listener” option in Edit>Options>Misc to sometimes not work as expected.


Hello, I think I am running into the same issue.

In my case I am running ImageJ on Linux with this command:

/g/almf/software/ --headless --mem=32000M --allow-multiple --run

However, the log file reports:

[INFO] Detected existing ImageJ; passing arguments along

@Wayne, I also tried:

Edit>Options>Misc>Run single instance listener

But it did not help.

This is quite an important issue for us as we are now routinely running ImageJ on a cluster and it is thus important to ensure individual instances, because otherwise different jobs start stealing resources from each other and will crash a.s.o.

Any help would be super much appreciated!


@ctrueden @imagejan

I guess I am probably super hyper naive here, but is the “–allow-multiple” maybe contained in the args in below code? If so could one simply check for it at this place?


I can’t reproduce the issue on macOS. Do you also observe this on Windows or is it just Linux?

EDIT: Is there anything else on the command line after invocation?


I just observed it on Linux (CentOS based cluster), don’t know about Windows, but given the comment of David (s.a.) it seems to be OK on Windows. I don’t know, maybe there are different ways depending on OS how it checks whether there is another running instance?

…after the --run I am starting an IJ2 Command.

I think the point would be to make sure that the --allow-multiple flag is properly checked. Do you think it would be part of the args in above code?


I did some more digging and I think this might not work in our current setup, because multiple users are executing the same central ImageJ installation. Now, when, e.g. I change the Prefs, this is saved in file in my home directory. Thus another user launching ImageJ will not see my changes in the Prefs.


I certainly sympathize with this problem, and personally feel that --allow-multiple is the wrong way around—the required flag should rather be something like --delegate-to-already-running-instance when you actually want to tell an existing instance something. Certainly there are many ways to fix this specific issue at various levels of hackishness. E.g., if --headless is specified, it should never (IMHO) hand off to an already-running instance.

FWIW, if your code were pure ImageJ2, with no ImageJ1 mixed in, you could simply purge imagej-legacy from your installation and then none of this would be an issue, since the instance listener logic is only part of ImageJ Legacy.

Unfortunately, I do not have time to look into the single instance listener behavior before mid-June. Either bug me again then, or at the upcoming DAIS Learnathon if anyone who cares about this issue is attending that.


There is a patch now that addresses many aspects of this issue:

On my macOS machine it now works to do the following in terminal A:

ImageJ-macosx -Dscijava.log.level:net.imagej.legacy=debug -- --force-single-instance -port2 --ij2 --open aPicture.jpg

And then from terminal B:

ImageJ-macosx -Dscijava.log.level:net.imagej.legacy=debug -- --force-single-instance --port2 --ij2 --open anotherPicture.jpg

And anotherPicture.jpg opens in the Fiji from terminal A. Conversely, if you pass --forbid-single-instance, the second Fiji will always stick, with single instance logic completely suppressed. See the commit and javadoc for more details. Feedback welcome.