Fiji breakage due to deprecated code moved to imagej-deprecated

[imagejan]

Moving the deprecated code to imagej-deprecated (2700e04) broke current Fiji installations.
My quick diagnosis:

• Running the updater automatically downloads imagej-common-0.18.0.jar and imagej-ops-0.20.0.jar after checksumming (without user confirmation) but not yet imagej-deprecated-0.1.0.jar because the updater dialog is not displayed.
• Restarting Fiji results in replacing imagej-commons and imagej-ops, but fails then because net.imagej.threshold.ThresholdService cannot be found (it is in the new imagej-deprecated artifact).

[imagejan]

A workaround is to update from the command line:

ImageJ-win64.exe --update update jars/imagej-deprecated.jar

See this thread on the ImageJ mailing list.

The issue might be fixed by declaring correct dependencies, e.g. making imagej-ops dependent on imagej-deprecated? On the other hand, why is imagej-updater dependent on imagej-ops in the first place?

[ctrueden]

Thanks for the analysis, @imagejan.

The weird thing is that I have been unable to reproduce the issue on my machine across several different Fiji installations at various states, including the 2014-06 Life-Line version.

I have also been thinking about how to fix the issue, but do not have a good solution yet. The imagej-ops component does not depend on imagej-deprecated.

The imagej-updater "depends" on imagej-ops as a workaround to this very same problem with the updater, to "fix" the last time things broke like this. I guess I'll add imagej-deprecated too. Ugh.

[ctrueden]

OK, I added a hardcoded imagej-deprecated dependency to imagej-updater, so that imagej-deprecated also gets downloaded when the updater does its minimal update.

To elaborate: when the updater itself changes, it applies the dubious strategy of trying to update only itself (and its declared dependencies) first, then relaunch, and then update everything else. Sometimes, there needs to be a restart in between those steps—I don't really understand the circumstances for that.

There are two things that need to happen to really fix this type of breakage in the future:

1. Make the launcher pass -Dscijava.context.strict=false when launching, to help the context spin up when certain services fail to initialize. This will mitigate the problem, but not fully avoid it in every case.
2. Change the updater so that it doesn't do that "minimal update first" approach, since it ends up doing more harm than good. Ultimately, I'd like to migrate to industry standard updater mechanism(s), but that is a huge can of worms, so it won't happen any time soon, unfortunately.

[imagejan]

Hm, that's strange.
When I started the updater (I tried on various installations that were last updated a day or a few weeks ago), it downloaded the follwing files into ./update/jars/:

imagej-common-0.15.1.jar
imagej-common-0.18.0.jar
imagej-ops-0.14.0.jar
imagej-ops-0.20.0.jar
imagej-updater-0.7.5.jar
imagej-updater-0.7.7.jar
imglib2-2.3.0.jar
imglib2-2.4.0.jar
imglib2-algorithm-0.3.0.jar
imglib2-algorithm-0.3.1.jar
imglib2-roi-0.3.1.jar
imglib2-roi-0.3.2.jar
scijava-common-2.43.0.jar
scijava-common-2.46.0.jar

without displaying the dialog to choose all other updated files.
When I then restarted ImageJ, the respective files got copied to ./jars/, but obviously imagej-deprecated.jar is missing, hence my suggestion to make imagej-ops dependent on imagej-deprecated.
It seems that on Mac OSX there's no restart needed between the small update and the big update, which might be the reason why you didn't see the issue??

Thanks for the update, I'll test right away.

[imagejan]

I vaguely remember cases where only the updated updater was able to get all the correct files (e.g. when update sites where first introduced, etc.), so in these cases it makes sense to first update the updater only, then re-run the updater, then update all the rest.

On Windows, since all the .jar files are locked by the system, this strategy need a full ImageJ restart however. This is the stack trace that's displayed (together with a nice dialog asking the user to restart) every time the updater itself gets updated:

[INFO] Trying to install and execute the new updater
java.lang.ClassNotFoundException: net.imagej.ui.swing.updater.ImageJUpdater
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    at net.imagej.ui.swing.updater.ImageJUpdater.run(ImageJUpdater.java:206)
    at org.scijava.command.CommandModule.run(CommandModule.java:201)
    at org.scijava.module.ModuleRunner.run(ModuleRunner.java:167)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:126)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:65)
    at org.scijava.thread.DefaultThreadService$2.call(DefaultThreadService.java:191)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619)

I tested now on another Windows installation, it seems thing are fixed for now. Thanks @ctrueden !

[ctrueden]

I tested now on another Windows installation, it seems thing are fixed for now.

😌

[ctrueden]

It seems that on Mac OSX there's no restart needed between the small update and the big update, which might be the reason why you didn't see the issue??

Right... but some people still saw the breakage on OS X. So color me confused...

[imagejan]

It seems that on Mac OSX there's no restart needed between the small update and the big update, >> which might be the reason why you didn't see the issue??

Right... but some people still saw the breakage on OS X. So color me confused...

Hm, maybe it makes a difference if you installed into /Applications/Fiji.app or somewhere else on OSX? Or if it's a multi-user system where the current user isn't an admin? Needs more info from the affected persons I guess...