Please test the new ImageJ Launcher!



Thanks for pointing that out, @mountain_man! I will look into it and report my findings here.


Everything should be back to normal now. I have restarted the builds on Travis and AppVeyor to see if the issue persists (which it doesn’t).

@ctrueden: Could you please check the Nexus configuration for the number of SNAPSHOTs that are kept? It might not be enough for our current deployment configuration since we have two versions per SNAPSHOT per OS (one for the regular build and one for the deployment of the binaries). Dunno if that’s the reason for the reported 404s, though. I just don’t see a better explanation for what has happened, especially since everything’s back to normal now.


I bumped the minimum snapshot count from 3 to 6, which will hopefully avoid this happening again in the future.

Note that SNAPSHOTs do still get deleted once a release is made. So e.g. once we cut 5.0.0, the 5.0.0-SNAPSHOT artifacts will disappear within 24-48 hours.


Hello Stefan,

Thank you, Stefan. I am now able to download all four versions
of the java-9 launcher from the four links in the original post.

Thanks, mm


Hi Curtis,

I’m a little late to the party, but I have taken a crack
at testing the new launcher.

I am unable to run Fiji with java 9 with the new launcher.
It looks like (among other errors) it can’t find a bunch of
standard java classes. (I am running stock Fiji on 64-bit
ubuntu 16.04 LTS.)

There is voluminous (error) output when I attempt to run the
launcher from the command line.

After hiding (renaming) Fiji’s java directory, I run both

user@x220-3:~/fiji_launcher9/$ ./ImageJ-linux64


user@x220-3:~/fiji_launcher9/$ ./ImageJ-linux64 --java-home /usr/lib/jvm/java-9-openjdk-amd64

The Fiji splash-screen/icon comes up for about two seconds but
the Fiji application never appears to start, and a lot of error
messages are printed to the terminal window.

For example, here’s one such error:

java.lang.IllegalArgumentException: Cannot modify method: void createPlugin(java.lang.String text, java.lang.String name)
	at net.imagej.patcher.CodeHacker.insertAtTopOfMethod(
Caused by: java.lang.IllegalArgumentException: No such class: java.lang.String
	at net.imagej.patcher.CodeHacker.getClass(
	at net.imagej.patcher.CodeHacker.getMethod(
	at net.imagej.patcher.CodeHacker.getBehavior(
	at net.imagej.patcher.CodeHacker.insertAtTopOfMethod(
	... 35 more
Caused by: javassist.NotFoundException: java.lang.String
	at javassist.ClassPool.get(
	at net.imagej.patcher.CodeHacker.getClass(
	... 38 more

Some details:

I have working java-9, installed as follows:

sudo apt -o Dpkg::Options::="--force-overwrite" install openjdk-9-jdk

user@x220-3:~$ echo $JAVA_HOME

user@x220-3:~$ which java

which resolves via a couple of symbolic links to

user@x220-3:~$ ls -l /usr/lib/jvm/java-9-openjdk-amd64/bin/java
-rwxr-xr-x 1 root root 6480 Apr 14  2016 /usr/lib/jvm/java-9-openjdk-amd64/bin/java

I can compile and run java programs:

user@x220-3:~$ java test_a1 
test a1

If I run a clean install of Fiji

user@x220-3:~/fiji_launcher9/$ ./ImageJ-linux64

Fiji launches and reports

ImageJ 2.0.0-rc-62/1.51s; Java 1.8.0_66 [64-bit];

If I rename Fiji’s java directory to java8_hide and run

user@x220-3:~/fiji_launcher9/$ ./ImageJ-linux64 --java-home /home/user/fiji_launcher9/

Fiji launches, reports the same version, and appears to
run correctly.

I now replace the launcher, ImageJ-linux64, that came
with the Fiji download with the new, java-9 launcher,
renamed to ImageJ-linux64 (and set to executable).

With Fiji’s java directory back in place, running the new

user@x220-3:~/fiji_launcher9/$ ./ImageJ-linux64


With Fiji’s java directory hidden again, running:

user@x220-3:~/fiji_launcher9/$ ./ImageJ-linux64 --java-home /home/user/fiji_launcher9/

also works.

However (with Fiji’s java directory hidden), the new launcher
fails when run both as:

user@x220-3:~/fiji_launcher9/$ ./ImageJ-linux64


user@x220-3:~/fiji_launcher9/$ ./ImageJ-linux64 --java-home /usr/lib/jvm/java-9-openjdk-amd64

Just to check the path:

user@x220-3:~/fiji_launcher9/$ ls /usr/lib/jvm/java-9-openjdk-amd64
ASSEMBLY_EXCEPTION  bin  docs  include  jmods  jrt-fs.jar  lib  man  THIRD_PARTY_README

Any thoughts would be appreciated.

Thanks, mm.


The launcher is not yet Java 9 compatible on Linux (and Windows as far as I can tell). There is a technical issue open on the topic:

If you feel adventurous, you can grab the fix-java9 branch from GitHub and compile a version of the launcher that should support Java 9. I haven’t had time to test and verify those fixes and won’t until next week.


@ctrueden: I assume those settings are per repository? We would actually need 8 ((Win32+Win64+Linux+macOS)*2) to cover a complete SNAPSHOT deployment. That would, however, also mean to increase the storage burden on the hardware running our Nexus instance. What do you think?


Per deployment. As you know (but I explain here for the benefit of anyone else reading), each deployment operation has a different timestamp on the SNAPSHOT. The “minimum number of snapshots” setting goes by the number of unique such timestamps. So we have AppVeyor, Travis CI Linux, and TravisCI macOS environments, right? Hence, in theory, 3 is enough. But since some disappeared prematurely, I may be mistaken after all. Let’s see if 6 is enough to prevent any future disappearances. The higher this number, the more disk is transiently required, especially if people push to master often during development of the same version.


AppVeyor 32-bit and 64-bit in individual tasks, hence individual timestamps. That’s how I came up with 8 instead of 6.

(also, I usually forget about that: thank you for looking into this, @ctrueden! :+1: :+1:)