Closed hinerm closed 1 month ago
what's odd to me is that we have always shipped an updated imagej-launcher.jar and this wasn't a problem in the past
I cannot imagine that this ever worked using the exact workflow you described, as long as it was Jaunch responsible for moving the files of the Fiji.app/update
folder into place and then immediately launching; #47 has always been a limitation of Jaunch since you first implemented the logic in #46.
Two theories come to mind:
Are we totally certain that this really worked in the past? I.e. that after enabling the SciJava Ops update site, then immediately running the Jaunch launcher once, it successsfully started up? I'd be surprised. At some point, weren't we running the classic ImageJ Launcher one more time to move the updates into place, and only then quitting Fiji and restarting with Jaunch with no pending Fiji.app/update
folder? And/or: maybe when we initially tested it, and running with jaunch didn't work, we just clicked it again, thinking we might not have double-clicked correctly? Could it be that simple?
I haven't looked closely in a long time, but my vague memory is that the classic Launcher might not always need to store pending updates into a Fiji.app/update
folder, depending on the platform? Are we certain that enabling the SciJava Ops update site via the ImageJ Updater created a Fiji.app/update
folder handled by Jaunch? I.e. are there cases (e.g. on non-Windows platforms) where it is simply able to move the new files directly into place during the same update operation?
In any case, regardless of the reason, the fix is the same: solve #47 somehow.
Are we totally certain that this really worked in the past? I.e. that after enabling the SciJava Ops update site, then immediately running the Jaunch launcher once, it successfully started up?
we have always shipped an updated imagej-launcher.jar
I was wrong - I was thinking of the Java update logic, but that's in imagej-ui-swing
. This likely worked in June when we submitted because imagej-launcher
wasn't modified at that point. It probably broke in July when this PR was merged to try and fix focus.
But https://github.com/apposed/jaunch/issues/47 seems like it's missing something, because every jar
except imagej-launcher
seems to be picked up fine on the initial update launch.
For example, I can do the following:
SciJava Ops
update siteFiji.app/update/jars
directory and remove the two imagej-launcher
entries. This will allow the Jaunch launcher to work on the first, update-application run.imagej-ui-swing
has an update in the update/jars
dirfiji-xxx
launcher. This will apply the update and successfully launch Fiji.Help > Update...
and we get the notice about updating Java.This Java upgrade logic is only in the new imagej-ui-swing
, which according to https://github.com/apposed/jaunch/issues/47 shouldn't be on the classpath until after another restart, right?
I'm not sure that this changes how we should approach https://github.com/apposed/jaunch/issues/47, but it feels like slightly different information.
Regarding Fiji still working when the imagej-ui-swing version changed and got updated in the same run: I'm guessing it's because the imagej-launcher.jar's ClassLoaderPlus
is taking care of recursively adding all the JARs to the classpath. I.e. if you didn't run ./fiji-<platform>
with the --full-classpath
flag, then Jaunch's classpath computation does not matter. Or rather, it almost doesn't matter... it still matters for imagej-launcher.jar because that's the bootstrapping JAR, so when that JAR changes, it won't start.
I'm planning to remove the ClassLoaderPlus
logic in favor of the --full-classpath
behavior always, which will certainly break Fiji startup more nastily after updates are applied! :scream_cat: Until apposed/jaunch#47 is fixed, of course.
To reproduce:
SciJava Ops
update site to get Jaunchfiji-xxx
launcherOn second launch, everything is fine.
This could be because of https://github.com/apposed/jaunch/issues/47 but what's odd to me is that we have always shipped an updated
imagej-launcher.jar
and this wasn't a problem in the past (and all the other.jars
on the update site worked on first launch, e.g. could use SJOps in the script editor)Debug output from initial jaunch launch: