Package org.eclipse.core.commands

package org.eclipse.core.commands
Application programming interfaces for commands and handlers.

Package Specification

This package provides API and implementation classes to define abstract pieces of functionality. These pieces of functionality are intended to provide a common way for plug-ins and the user interface to communicate potential behaviour.

This package is designed so that its elements can be public and dynamic. That is, elements in this package can appear and disappear over the life of the application.


A command is an abstract representation for some semantic behaviour. For example, there might be a "copy" command. How this command actually behaves might be dependent on what state your application is in. It is not the actual implementation of that behaviour, and it is not the visual representation of that behaviour.

Commands are managed by an instance of CommandManager. In fact, a command cannot be constructed directly. Commands are constructed using the method CommandManager.getCommand(String). This ensures that there is only ever one command with a given identifier ever associated with a command. manager.

When a command is first constructed, it is undefined. An undefined command is one that is carrying no information except for an id. Attempts to interact with a command that is undefined will result in a NotDefinedException. Through this mechanism, it is possible for clients to hold references to commands, and still have those commands "disappear" (i.e., become undefined). This is particularly useful in a system built around dynamic components (e.g., plug-ins).

Commands can be grouped into categories. These categories are arbitrary groupings, and have no defined behaviour. These categories might be used in a user interface for breaking up a large list of commands into semantically similar commands -- making the list easier to navigate.

It is also possible to attach listeners to both commands and command managers. A listener on a command manager will be notified if the list of defined commands or categories changes.


        CommandManager manager = new CommandManager();
        Category category = manager.getCategory("categoryId");
        category.define("name", "description");
        Command command = manager.getCommand("commandId");
        command.define("name", "description", category);

This example shows how to create a command from scratch -- with no existing manager or categories.

        command = null;
        category = null;

If you wish to get rid of the command, then you simply undefine it. This will send notification to the appropriate listeners, and future attempts to access it will fail. If you are the only one holding on to the command, then it will be garbage collected. However, if other people still have a reference to the command, then the stub will remain until they respond to the change.

        String name;
        try {
                name = command.getName();
        } catch (NotDefinedException e) {
                // Clean-up my reference to the command.
                command = null;

This shows one way of dealing with commands. Instead of listening for changes to the command, you can simply listen for the exceptions to be thrown. When a NotDefinedException is thrown, you can clean up your own code. How you clean up is application dependent. In this case, the reference is cleared and we return from the method.

        try {
                String name = command.getName();
                // Do all your work in the block.
        } catch (NotDefinedException e) {
                // Ignore, or possibly throw an error
        public commandChanged(CommandEvent e) {
                if (e.hasDefinedChanged()) {
                        command = null;

Another way is to attach a listener, and then simply ignore the exceptions. When the command becomes undefined, you will be notified. This gives your the opportunity to unhook your listener and release your reference.


A handler is the behaviour of a command at a particular point in time. This is the piece that will actually interact with your application model. For every command, there can be zero or more possible handlers. However, at any one time, there is either one handler (i.e., handled) or no handler (i.e., unhandled).

Handlers must implement IHandler. However, there is a convenient abstract class, AbstractHandler which provides default behaviour for some of the methods in the interface. It is recommended that developers subclass AbstractHandler.

Beside functional behaviour, a handler carries with it a map of attribute values. This is a completely optionaly way of carrying extra data. In the case of the AbstractHandler, this map is empty. Some attributes have well defined meanings. These attributes are defined in IHandlerAttributes.

Like commands, handlers can have listeners attached to them. Listeners will be notified when the attributes of the handler change.

When a handler executes, it is passed an event object (ExecutionEvent) that carries with it some pieces of information. First of all, it contains the parameters for execution. Parameters are simple key-value pairs that are intended to modify the execution in some way. The event also carries with it a collection of contexts that were active at the time of execution. The event also carries two untyped objects: the triggering event and the current application state. In the case of a graphical tool, the triggering event is likely to be the underlying widget toolkit event. The application state might contain information like widget focus information. In your own application, feel free to use whichever of these event attributes that fit your application.


        IHandler myHandler = createHandler();
        ExecutionEvent e = new ExecutionEvent(parameters,contexts,trigger,state);
        try {
        } catch (ExecutionException ex) {
                // Notify the user, log the problem, etc.