Why is EventListenerList traversed backwards in fireFooXXX()?

Question

I don't understand the rationale of this code, taken from javax.swing.event.EventListenerList docs:

protected void fireFooXXX() {
    // Guaranteed to return a non-null array
    Object[] listeners = listenerList.getListenerList();
    // Process the listeners last to first, notifying
    // those that are interested in this event
    for (int i = listeners.length-2; i>=0; i-=2) {
        if (listeners[i]==FooListener.class) {
            // Lazily create the event:
            if (fooEvent == null)
                fooEvent = new FooEvent(this);                 
            ((FooListener)listeners[i+1]).fooXXX(fooEvent);
        }
    }
}

1. Why is the list traversed backwards?
2. Why is only every second listener called?

The event firing is implemented exactly this way in javax.swing.tree.DefaultTreeModel among others, so it's obviously me who's just not getting something.

Answer 1

1.

One possible problem when traversing listeners is described in Swing Hacks item #94, and happens if one of them removes itself as a listener in it's implementation of fooXXX().

Consider this listener, that might remove itself after receiving the event:

public class FooListener implements EventListener {
   private int i;

   public FooListener(int i) {
       this.i = i;
   }

   public fooXXX(FooEvent foo) {
       System.out.println(i);
       if (i == 1) {
           ((FooEventSource)foo.getSource()).removeListener(this);
       }
   }
} 

and this implementation of the listener traversal:

public void fireFooXXX() {
   for (int i=0; i<listeners.size(); i++) {
      // Lazily create the event:
      if (fooEvent == null)
         fooEvent = new FooEvent(this);
      listeners.get(i).fooXXX(fooEvent);
   }
}

Now suppose we create a number of these listeners:

fooEventSource.addListener(new FooListener(0));
fooEventSource.addListener(new FooListener(1));
fooEventSource.addListener(new FooListener(2));
fooEventSource.addListener(new FooListener(3));

Firing the event would give the following output:

0
1
3

We would be looping over the listeners by index, from 0 to 3. At index 1 the listener removes itself from the internal array of listeners, causing listeners 2 and 3 to be shifted down to index 1 and 2. The loop continues with index 2 which now contains listener 3. Listener 2 has been skipped.

By iterating backwards this problem is eliminated since removing a listener would only shift the index of listeners that have already been called.

But

EventListenerList does not have this problem, since the add() and remove() methods are copy-on-write and the listener traversal in the suggested usage operates on the listener list instance returned by getListenerList() before the loop.

Some more discussions about it can be found in this thread, where the reasons seems to boil down to one of:

• performance

• event ordering (the last added listener will be the first to be notified)

---

2.

akf and Michael Borgwardt has already answered that the EvenListenerList stores the listener types in addition to the listeners. I guess the reason for this is that it makes it possible for a single EventListenerList to handle listeners of different types.

Answer 2

1. Probably performance considerations: backwards iteration is faster because comparison with 0 is a single machine code instruction - lots of former C programmers have that ingrained even though it's rather irrelevant nowadays. Note that there is no guarantee about the order in which listeners will be notified anyway.
2. Look at the rest of the class - it stores the listeners' types as well to provide type safety.

Answer 3

to answer #2: Every second listener is called because the array that EventListenerList uses is set populated as an array of Listener-Type, Listener-Instance pairs.