Add logic for migrating to Jaunch launcher #94
Conversation
ctrueden
commented
Nov 19, 2024
ctrueden
commented
- Update license blurbs for 2024
- ImageJUpdater: let any/all services be null
- ImageJUpdater: Do not update the updater separately
- WIP: Add logic for migrating to Jaunch launcher
The code was already written to support the services not being set, with various fallbacks in place. So let's mark the params accordingly.
The removed code does the following:
* check if the updater can be updated
* if yes, download updater and it's dependencies and install it,
do not ask for approval
* try to restart the updater in place
* if that does not work, ask for restart of Fiji
This is why it should be removed:
* if other components depend on the updater, this can break the installation
because the other component will not get updated at the same time as the updater
* the updater will be updated without the users approval
CTR: I asked Johannes why this logic was introduced. Here is what he said:
> The reason was dependency hell. If you don't update the updater first,
> then create a new class loader, then re-load the updater and run it,
> it really can break everything, especially when imagej-ui-swing is
> updated (and not necessarily the updater).
CTR: So really, there are things that can go wrong either way. In the
interest of simplicity, we remove the logic. If all hell breaks loose,
we can put it back, and deal with the fallout as best we can. But I
expect that removing this logic will fix more problems than it causes.
Closes #83.
Signed-off-by: Curtis Rueden <[email protected]>
ctrueden
force-pushed
the
new-launcher
branch
5 times, most recently
from
7e3a1fe to
6cfcad4
Compare
ctrueden
force-pushed
the
new-launcher
branch
from
4c3fc6e to
cb78283
Compare
|
Note that some of the art on the update buttons does not render on windows:
|
|
Other problems: I mentioned here that when I build Jaunch locally, copy it over to a However, this also happens if I copy jaunch executables to a
Incidentally I also opened fiji/fiji#375 but that is probably related to how the restart is being handled, also. Maybe we shouldn't do the auto-restart for the user? It may be too magical and on non-Mac I can see people being confused about having to use a different executable. We probably want to tell them to remove their |
|
Here are some alternative art sequences that replace the broken characters in the screenshot above with ASCII ones:
|
This is precisely why I did code up the auto-restart: so they don't need to choose correctly between |
I see. I guess an upgrade has never fully succeeded on my system so I was not aware that the
|
Nah, the rename of the old executable just isn't implemented yet by the migrator.
Great! |
It won't be the "future" much longer...
ctrueden
force-pushed
the
new-launcher
branch
from
82b4bd3 to
819ffef
Compare
|
The upgrade process is currently broken for me (after reverting 44459b1). Also, using the Jaunch launcher keeps telling me to upgrade Java but agreeing to upgrade seems to do nothing. ^ Fixed in fiji/fiji@dbe4f8e |
Otherwise this will throw an exception, making the check for completion irrelevant and possibly leaving a dangling process.
|
OK well first of all reverting that commit is insufficient. Also need to comment out this UnsupportedOperationException. Second of all, this process logic is hanging on my system (with timeout bumped up to 100) Confirmed that the process command works by itself. Thread dump of the ^ Fixed in d8f0d20 |
If the process's output stream isn't read from, the buffer will get too full and the process will block. Thus our process.waitFor call will never finish. We need to instead read the process output in parallel as we wait for the process to finish.
For current testing. Rewrite with 44459b1 if addressed before merging to mainline
Calling System.exit is generally something we try to avoid. Disposing the context beforehand is kinder and avoids some problems such as deadlocking during frame disposal.
hinerm
force-pushed
the
new-launcher
branch
2 times, most recently
from
52da771 to
b1ee0bb
Compare
Discourage the use of the ImageJ* launchers which do not use Jaunch and cannot handle modern JVM's (e.g. 21)
