Support refresh menus

[hinerm]

This is a useful function of ImageJ and it is unfortunate that we have had to drop its support to perform class modification magic.

It would be nice to restore this functionality.

[hinerm]

@dscho If you get a chance could you post some information here about the challenges of refresh menus in Fiji? Or if this is ticketed in a different component, and I just missed it, please let me know. Thanks!

[dscho]

I agree that it would be nice to reinstate that feature.

However, it is so much easier to ask, ask again, and then ask another hundred times for it to be reinstated, than it is to understand all of the ramifications. It is a very tricky business and it never works fully anyway (whenever plugins install something ImageJ 1.x does not handle in Refresh Menus there are class version conflicts, resulting in nasty ClassCastExceptions between apparently-identical classes!).

[hinerm]

If it's not technically feasible or realistic to implement this, then let's absolutely close this issue with a "won't fix."

But I personally am ignorant of the issues or nuances of this functionality, both in how it works in IJ 1.x and any attempts to implement it in ImageJ2. We should at least have a link to point to for anyone who is interested in refresh menus, explaining precisely why we can not pursue it. Then my interest would be satisfied as well :)

If there is already a public discussion of this then just point me to it! :) My impression was that explanations have come up in private or offline communication.

[dscho]

Okay, here come the technical details as far as I can pull them off the top of my head right now...

We must start with a much more complete classpath than ImageJ 1.x. There are two reasons for this:

1. ImageJ2 is much, much better separated into individual modules with their own concern. These must be on the class path, and we cannot have a single component (imagej-legacy) require to be able to modify said classpath.
2. The plugin framework requires the ImageJ2 plugins to be on the classpath when the context spins up. That means that allowing ImageJ 1.x to rewrite the class path would completely mess up the SciJava context.

Now, there are a couple of ideas I had in the past, all of which but one I rejected (although you might have a different preference):

• disallow Help>Refresh Menus. This is the safest option, and I went for it
• shutdown the old context and spin up a new context whenever ImageJ 1.x wants to refresh the menus (which is a misnomer, BTW, it does substantially more than just refresh the menus). This was possible with the old startup mode when ImageJ2 was basically an add-on to Fiji. Now ImageJ2 starts up and Fiji is extending ImageJ2's functionality through regular SciJava plugins (e.g. the application name and icon). Therefore, this option is no longer feasible.
• initialize the class path just with ImageJ2 and then use a special class loader similar to ImageJ 1.x' PluginClassLoader that is thrown away and recreated upon Help>Refresh Menus. The problem are the SciJava plugins discovered only through that class loader: it is finicky at best to remove them when the class loader is thrown away and add new ones based on the recreated class loader. Not to mention that services such as the SingletonService would have to release the instances using now-obsolete class definitions.
• install a special class loader that prefers new class versions over old ones, except the ImageJ2 ones. This would be kind of OSGi, but using the information available through Maven instead of forcing the developer to provide special OSGi information ("bundle" information). The exact same problems apply as for the previous option.
• install a ton of class loaders, i.e. recreating OSGi more faithfully: every class path element would have its own class loader and the hierarchy would have to be inferred through the Maven information. This is fragile because many software components lack that information or have incorrect information (think Bio-Formats). And it has the exact same problems as the previous option.
• require jars/*.jar to stay constant, i.e. do not rediscover the class path inside that directory, add only those to the initial class path (not plugins/**/*.jar), and require SciJava plugins to live in jars/ so that the PluginService discovers them properly and is not affected by the throwing away of ImageJ 1.x' PluginClassLoader. This would break TrackMate, for example, because TrackMate uses the SciJava plugin mechanism for its own plugins (a few of which it ships in plugins/TrackMate_-*.jar and wants to be discovered).

I also have to add that all those who ask for Help>Refresh Menus to work again 1) willfully ignore that the whole concept is broken due to so many ways the old class definitions are retained, leading to ClassCastExceptions as well as PermGen depletion, and 2) insist on using inefficient development models.

That latter point requires a little more in-depth explanation: the only two reasons why you might want to call Help>Refresh Menus are: 1) new plugins have been installed, or 2) new plugin versions are installed as part of the modify/compile/test cycle so common in software development. As to 1), I have to admit that I deem it perfectly acceptable to ask for a restart of Fiji/ImageJ after installing plugins. It is a one-time cost, and that's that. As to 2), there are Eclipse, Netbeans and IntelliJ. All of them have built-in debuggers and all kinds of niceties. I can understand that you do not necessarily want to use those programs if you do not know about their advantages. I cannot understand how anybody who wants to develop Java plugins can fail to learn about the features of proper IDEs.

In short, I am convinced that my decision to disable Help>Refresh Menus was the correct one. The only evidence that would convince me otherwise will never be available, because I will no longer listen to the loudest people on the mailing list, I would only have listened to anonymous user statistics.

[hinerm]

mmm... technical details drools

Thank you @dscho !

[dscho]

@hinerm you are welcome! And also: you are awesome! Maybe you can think of the option I forgot, and that may work!

[ctrueden]

Since we are definitely not planning to reintroduce the Refresh Menus functionality, I am closing with a "won't fix" here. Fortunately, @hinerm added an informative message (776bc7b) when you try to use Refresh Menus explaining that ImageJ should be restarted. So hopefully that is good enough.