(Experimental PATCH) Allow plugins to be reloaded without restart

[olejorgenb]

I have a tendency to test my code very (or maybe too ;) often so I'm starting to get pretty sick of watching the JOSM load screen by now.

Decided to scratch my itch, and here is the result.

The patch introduces a new method in Plugin called preReloadCleanup. All loaded/active plugins implementing this will be reloaded when ReloadPluginsAction is performed. (They don't have to use Plugin as a baseclass)

It's not really tested beyond checking that the new classes actually are loaded and used. Would be beneficial if a java guru could take a look and see if my classloader magic is mostly correct.

Known limitations:

1. If p1 requires p2 and only p2 is re-loadable, two versions of p2 will be in use. That can't be good. (Not checked, but I'm quite sure this applies)
2. checkLoadPreconditions is not run on the plugins before reload. Fair to assuming the conditions are fulfilled as the plugins are already loaded, but it isn't 100% correct.
3. Doesn't respect the early/late flags. Is that important?
4. Probably need more functions in MapFrame supporting preReloadCleanup. (only removeMapMode is implemented now)

This feature is mostly for the plugin-developer's benefit, so it doesn't have to be perfect before inclusion, IMHO.

[olejorgenb]

Git branch: ​https://github.com/olejorgenb/josm/tree/plugin-reload

[bastiK]

Sounds very interesting.

If the reload process is split into unload and load part, the user could install and uninstall plugins without restart. This would be a significant improvement.

Diff view of olejorgenb's branch: ​https://github.com/olejorgenb/josm/compare/plugin-reload

[olejorgenb]

Yes, eventually that should be possible. Integrating it with the preferences gui might be some work though, and featuring it like that will require a higher level of stability. Having a solution with some quirks would still be beneficial to developers.

New patch with a couple fixes attached. (against r4104)

[olejorgenb]

Preliminary documentation

[bastiK]

Replying to olejorgenb:

Yes, eventually that should be possible. Integrating it with the preferences gui might be some work though,

The simplest possible solution, wouldn't require any GUI extension. Currently, when the user selects some plugins in the preferences and confirms with "OK", JOSM shows a dialogue to request a restart. When all of the selected plugins can be loaded at runtime, this dialogue would simply be omitted and the user could continue the work. Similarly, when the user uninstalls certain plugins, they could be unloaded at runtime and no restart would be required.

I think the first use case is more common and easier to implement.

and featuring it like that will require a higher level of stability. Having a solution with some quirks would still be beneficial to developers.

Do you know the hot swap feature built into IDEs like eclipse or netbeans? It has its limitations but generally it's quite a time saver.

However I'm not sure, everyone is using an IDE, so "plugin reload" is still worthwhile.

[olejorgenb]

Do you know the hot swap feature built into IDEs like eclipse or netbeans? It has its limitations but generally it's quite a time saver.

Well, yes, but I didn't knew you could make it work with plugins (so easily). Guess I should have tried, as it worked out of the box. *blush* Pure magic!

Hehe, well now I feel a bit silly. Guess my work won't be totally wasted if I/we can make it stable enough for users though :)

Of course, making a plugin re/deloadable requires support from the plugin, and if plugin-writers don't benefit from adding that, few will probably support it. (although I think it should be very easy for most plugins)

Simply loading a new plugin is a lot less tricky. This is probably the most interesting case for users too. And it would have taken significant less time to figure out ^^. Oh well, I did learn a few bits of java technicalities in the process.

However I'm not sure, everyone is using an IDE, so "plugin reload" is still worthwhile.

Maybe. But wouldn't it be fairly painless to use eclipse just for hot swapping? (You can make eclipse auto-refresh the workspace)

I guess I should add a section about this to the developers guide.

[bastiK]

Replying to olejorgenb:

Do you know the hot swap feature built into IDEs like eclipse or netbeans? It has its limitations but generally it's quite a time saver.

Well, yes, but I didn't knew you could make it work with plugins (so easily). Guess I should have tried, as it worked out of the box. *blush* Pure magic!

Isn't so obvious after all, I guess some documentation is needed.

Hehe, well now I feel a bit silly. Guess my work won't be totally wasted if I/we can make it stable enough for users though :)

Of course, making a plugin re/deloadable requires support from the plugin, and if plugin-writers don't benefit from adding that, few will probably support it. (although I think it should be very easy for most plugins)

It will probably be you, Dirk and me who adapt the existing plugins. Fortunately, there is no need to rush, it can be done one by one. When most of the plugins are adjusted, authors will pick up the pattern for new plugins.

Simply loading a new plugin is a lot less tricky. This is probably the most interesting case for users too.

I agree.

[bastiK]

Replying to olejorgenb:

I guess I should add a section about this to the developers guide.

Thanks for the doc, the other tip is good as well.

[stoecker]

@bastiK:

Ready for inclusion?

[olejorgenb]

Replying to stoecker:

Ready for inclusion?

Well, unless someone else have done something its not :)

[Don-vip]

Closed as duplicate of #11090.

[bastiK]

See #11090 for loading a plugin at runtime. This ticked therefore is about the "unloading" and "reloading" part, which is more difficult, especially with plugin dependencies.