Eclipse has quite a bad reputation for requiring extremely verbose code for plugin development. As a developer, I constantly look for ways to make life easier for myself rather than having to produce lots and lots of code. Here is one way of reducing the code required to handle an eclipse ‘command’ extension.
I was recently tasked with adding a “Global Menu” to eclipse to present the user with shortcuts for some plugin features that my colleagues have been working on. Traditionally, when adding an extension to eclipse, you would create a menu with entries linked to different commands and each command would require a unique handler object that implements the org.eclipse.core.commands.IHandler interface. This approach is shown in the adjacent diagram. Although commands themselves don’t have any code behind them (they are typically specified in 2-3 lines of XML inside the plugin file), all of the handlers have concrete implementations which means loading each individual class into memory (we’re not talking Gigs or even Megs here, but hell, every little helps right?).
Rather than implementing a new Handler class for every command, I chose to use a single handler class for a whole menu and use the Command ID (specified in the plugin XML) to decide what action to undertake. This cuts down the number of classes loaded into the virtual machine, the number of files that need to be updated in the event of a code change and therefore the efficiency of my plugin. Running a few comparisons on Java strings (which are just wrappers for char[] arrays) is much cheaper, memory and performance-wise, than loading up lots of small classes in the JVM.
Plugin XML Definition
In my plugin.xml file, I have several commands set up, each with the same argument for their defaultHandler.
<!-- Command definitions --> <extension point="org.eclipse.ui.commands"> <command commandId="uk.co.roarc.commands.commandA" id="uk.co.roarc.menus.commandA" mnemonic="A"> </command> <command commandId="uk.co.roarc.commands.commandB" id="uk.co.roarc.menus.commandB" mnemonic="B"> </command> </extension> <!-- Handler definitions --> <extension point="org.eclipse.ui.handlers"> <handler class="uk.co.roarc.internal.ui.handlers.MenuHandler" commandId="uk.co.roarc.commands.commandA"> </handler> <handler class="uk.co.roarc.internal.ui.handlers.MenuHandler" commandId="uk.co.roarc.commands.commandB"> </handler> </extension>
Handler Code
The main method that we are concerned with within the handler is execute. Inside this method, we can find out which command was called by Eclipse through the getCommand().getId() method and therefore carry out the appropriate response.
public class MenuHandler implements IHandler { ... ... ... public Object execute(ExecutionEvent event) throws ExecutionException { String cmdID = event.getCommand().getId(); if(cmdID.equals("uk.co.roarc.commands.commandA")){ Activator.log(new Status(Status.INFO, Activator.getPluginId(), "Caught action A...")); }elseif(cmdID.equals("uk.co.roarc.commands.commandB")){ Activator.log(new Status(Status.INFO, Activator.getPluginId(), "Caught action B...")); } return null; } ... ... ... }
Finally…
This trade-off becomes less worthwhile as you add more and more commands to the same handler as more comparisons may have to be made before the right course of action is found. My rule of thumb is to stick to one handler per menu or toolbar. However, I still recommend using multiple handler classes within a plugin project unless you want things to get really ugly, really quickly.







