ListenerList - a better way to manage your event listeners

You have published a listener interface and have a place where your clients register their listeners. There you typically code like this:

List<SomeEventListener> listeners = new ArrayList<SomeEventListener>();

public void addSomeEventListener(SomeEventListener listener) {
    listeners.add(listener);
}

public void removeSomeEventListener(SomeEventListener listener) {
    listeners.remove(listener);
}

public void fireSomeEvent(SomeEvent event) {
    for (SomeEventListener listener : listeners) {
        listener.eventOccured(event);
    }
}

The problem with this approach is two fold:

1. Memory usage: The capacity of the ArrayList is always >= its size. So if you just have 200 listeners, there is a good chance that the memory might have been allocated for 300 elements
2. Thread safety: Murphy's law will prove itself, and multi threaded bugs can be a pain in your back to debug. You have to properly sync all the write access and provide faster read only access for event firing operations.

To handle these two issues, Eclipse gives you a nice API: ListenerList class. Its meant for storing these kind of listeners, where any write modification to the underlying array (add, remove, clear) is synchronized and give access to the underlying array for faster read access. Memory is allocated only for the number of listeners registered.

The same above example can be rewritten as:

ListenerList listeners = new ListenerList();

public void addSomeEventListener(SomeEventListener listener) {
    listeners.add(listener);
}

public void removeSomeEventListener(SomeEventListener listener) {
    listeners.remove(listener);
}

public void fireSomeEvent(SomeEvent event) {
    Object[] listenersArray = listeners.getListeners();
    for (int i = 0; i < listenersArray.length; i++) {
        ((SomeEventListener)listenersArray[i]).eventOccured(event);
    }
}

ListenerList provides two ways of duplicate checking of the listeners: Equality and Identity. It can be specified in the constructor. Since the core Eclipse platform is in Java 1.4, you still can't use generics and foreach, but that shouldn't be a hindrance.

Question: Now that I do have a direct access to the underlying array, what if i manipulate it like this:

Object[] listenersArray = listeners.getListeners();
listenersArray[0] = null;
listenersArray[1] = someEventListener5;

Well, the same thing happens when you shoot yourself in the foot :-)

Whats cooking in M4?

3.5 M4 will be out soon. There are numerous bugs & enhancements that got fixed in this build. Here are my favourites:

Customize perspective dialog:

The customize perspective dialog was there earlier, but it allowed the user only to customize Shortcuts and Commands. Now you can customize toolbar and menu as well:

Help icon:

If you have not noticed the difference in the above dialog, its good. Because the bigger icon that was added to M3 was too bright and pulled your attraction, which it shouldn't. So the new icon is now a little lighter in colour. Somehow I feel that the old 16x16 icon was better :-)

Java Action sets in all perspectives:

If you are editing a Java file, you can access your favourite actions (Open Type etc) in a non-java perspective as well (CVS, Resource)

Dead Code identification:

After all the optimizations you did and the refactorings your replacement guy did, the code might have been left with lot of dead code. JDT helps you find them easily and remove them with this option:

 

Editor for the .options file:

Well, not really. But it opens with the properties file editor, which is more than sufficient that the plain old text editor

There's lot more, keep looking for the New and Noteworthy page when M4 is announced...