Supporting Plug-In Dependencies In OpenJUMP

I was giving some thought this afternoon to how we might support plug-in dependencies in OpenJUMP. (A plug-in dependency means that one plug-in requires that another plug-in be installed and initialized before it will work.)


I really want to avoid a complicated system with a lot of overhead. The plug-in system in Eclipse is an example of this. (I’m not saying that the plug-in system in Eclipse doesn’t work very well, because it does. I do almost all of my Java programming in Eclipse.) One of the things I’ve always admired about JUMP/OpenJUMP is the simplicity with which the program can be extended.

In OpenJUMP’s current design Plug-Ins must implement the initialize() method. This method is called by OpenJUMP when the plug-in is loaded into the program. (A plug-in that is loaded into OpenJUMP doesn’t usually perform any tasks for the user at that point. It is just “initializing” or setting itself up for use. In my humble opinion a Plug-In should do as little work as possible in the initialization() method. This will keep OpenJUMP’s memory footprint and start-up time as small and as short as possible.) In this current system I have no way to design a plug-in with classes or interfaces that depend on classes or interfaces in another plug-in. If you want to use a class or interface in your plug-in code you have to include it in your plug-in or make modification of the core. This isn’t the best system, as it means most plug-ins can’t be designed to be extendable themselves.

An example of this is when I first began working on OpenJUMP’s CursorTools. I wanted to have a class that could be used to manage the active or current CursorTool, and that provided utility methods to this CursorTool. I wanted this class to be loaded as a plug-in, but to be available to other CursorTool plug-ins. How do you do this without support for plug-in dependencies or modifications to the core? There might be a hack, but it would be ugly.

Here is my idea for one solution to supporting plug-in dependencies in OpenJUMP. Remember that this is just an idea. I haven’t thought it completely through, and I’m sure there are alternative solutions that we can consider.

We will add a method named plugInsInitializationCompleted() to the PlugIn interface and the AbstractPlugIn class. This method will be called on each plug-ins after all of the plug-ins have been loaded. This method will be passed an object that contains an array or Collection of identifiers of the plug-ins that have just been successfully loaded and initialized by OpenJUMP. If they need to verify a dependency, plug-in developers can, within this method, check the list to make sure the plug-in they are dependent on was successfully initialized. If it was not, they can produce a warning to alert the user, or they can disable their plug-in.

This system works on the principle of “event-based” programming. Each plug-in is an event listener, OpenJUMP is the event broadcaster, and we have an event that indicates plug-in initialization has been completed.

This system will avoid the need of external files that define plug-in dependencies. Each developer will add that logic to the plugInsInitializationCompleted() method of their own plug-in implementation.

The Sunburned Surveyor