Ticket #877 (closed enhancement: wontfix)
Opened 2011-11-21T10:56:26-06:00
Last modified 2014-11-25T16:42:31-06:00
Consider whether we can have a Help>Refresh Menus
| Reported by: | dscho | Owned by: | dscho |
|---|---|---|---|
| Priority: | major | Milestone: | imagej-2.5.0 |
| Component: | Other | Version: | |
| Severity: | major | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
Original ImageJ 1.x has a feature where you can drop new or updated .jar files in the plugins/ directory and hit Help>Refresh Menus which then picks up the changed plugins and adjusts the menus.
There were substantial problems with classes still in use whose corresponding .jar files were updated.
So we need to think seriously about whether we can support this feature, or a stripped-down version thereof, or go the Eclipse way ("We really recommend you restart now. Do you want to restart? Hint: you should say yes").
Change History
comment:1 Changed 2012-01-19T12:45:01-06:00 by dscho
comment:2 Changed 2012-02-27T16:01:27-06:00 by dscho
The ij-launcher acquired the method ClassLauncher.restart() for exactly that purpose. This required a bunch of changes in both ij-launcher.jar and ImageJ.c:
- ClassLoaderPlus learnt how to discover class paths both for setting the class loader's class path and for setting a "-classpath <path list>" parameter for things such as javac or javadoc.
The relevant code is accessible via ClassLauncher's -classpath, -ijclasspath, -jarpath and -ijjarpath options which add a class path or all .jar files in a given directory and all its subdirectories. The options prefixed by '-ij' look specifically in locations relative to the ImageJ root directory, no matter what the current working directory may be.
- the ImageJ launcher no longer discovers any class path itself, but rather hands off to ClassLoader which in turn hands that task over to ClassLoaderPlus.
- ClassLauncher now remembers the original command-line arguments, including -classpath and friends. This allows us to restart ImageJ rediscovering all the available .jar files (even if some might be removed or added).
Furthermore, the ClassLauncher also supports the option to start a completely independent main() method of a given class using a new class loader. This will allow us to start only a new version of the Updater without affecting anything else ImageJ2 (although we can no longer put the ImageJ2 Updater window into the existing Window menu when we do that, but that is a minor annoyance in this developer's opinion).
If need be, we might consider adding yet another ClassLoader implementation which always searches in the given class path first before handing off to the parent class loader. This might even allow us to replace just the Updater and nothing else!
comment:4 Changed 2014-05-11T09:39:45-05:00 by curtis
- Status changed from accepted to reviewing
Dscho, can you comment on the current thinking with respect to this feature? I'm guessing that at this point, this ticket can be closed as either "fixed" or "wontfix" thanks to imagej-legacy's new tiered class loader approach.
comment:5 Changed 2014-11-25T16:42:31-06:00 by curtis
- Status changed from reviewing to closed
- Resolution set to wontfix
We won't be able to support this any time soon.
With the current ImageJ launcher, there is a minimal ij-launcher.jar with support classes. This .jar file is the only one in the system class path, to allow for relaunching any class with any class path (except the three classes in ij-launcher: ClassLauncher, JarLauncher and ClassLoaderPlus).