Closed dscho closed 9 years ago
@ctrueden @hinerm I three more ideas about which I wanted to let you comment:
main
method triggered, could be useful information. So maybe it should be injected into the Javascript engine, as cause
variable, and handled by bootstrap.js
? (The JTextArea
would then need to be wrapped into a JScrollPane
, complicating the script further, but I think it would be a valuable change.)EXIT_ON_CLOSE
up until the classes are loaded successfully (and after that switch to DISPOSE_ON_CLOSE
to prevent our own dispose()
call from exiting the whole process; I might be wrong about that, though, haven't yet tested).Answering myself:
The exception itself, the one that the main method triggered, could be useful information.
It is, and now it is even shown. Maybe the message should be improved, though.
The user might not want to run the remote updater at all; should we give them a chance to say "no"?
I tested this: closing the window triggers a shutdown of the JVM.
As long as the remote updater has not been loaded, the user will see that text window, but if that window is closed, the process will still go ahead.
In the test mentioned above, this was not the case. Closing the window quit the launcher.
So from my side, this is ready to merge.
Okay, now it is really ready to merge... @hinerm @ctrueden who wants a free commit? ;-)
Every once in a while (and more so in the beta phase) things do not quite work well together in the ImageJ startup. Even after the ImageJ components stabilize, with the flexibility of the SciJava service framework, it is possible for third-party components to interfere inadvertently with a successful SciJava context initialization.
In such cases, the user is stuck with a non-functioning setup at the moment.
Let's be nicer and use the fallback procedure established in Fiji (when the updater moved into ImageJ2) to help users get back to a working system: detect when the
main
method could not be called successfully and start the updater remotely, viabootstrap.js
.