There are many good resources on using events and implementing event listeners. Unfortunately, there are nearly as many resources that incorrectly or inefficiently implement event generators. These implementations introduce subtle nondeterministic errors, execute slowly, and/or fill the virtual machine with unnecessary garbage. The goal of this article is to address this problem once and for all - as a pattern and code generator for JDKs before 1.5, and as a set of generic types in JDK 1.5 and later.

Most Java programmers learn how to listen early on, usually thanks to the Swing classes. The elements are as follows:

• An event, which is the information to exchange.
• A listener, which receives the information.
• A generator, which sends the information. Listeners can be added (or removed) from generators as they become interested (or disinterested) in the events they send.

Here's the rub. These things are often not correctly accounted for:

1.  Adding and removing listeners may happen asynchronously. That is, different threads may add or remove listeners at somewhat inconvenient times.
2.  In response to listening to an event (and so synchronously), a listener may add or remove itself or other listeners from a generator.
3.  Generators may choose to send events asynchronously.

These are all issues of correctness. Issues of efficiency are:

1.  Most generators spend most of their life sending events (as opposed to adjusting who is listening).
2.  The average number of listeners for each generator is significantly less than one.

The humble truth is, most of the generators in your application are not being listened to by anything, and most of the rest have one listener. For example, of the 18 events generated by a JButton, how many do you actually pay attention to?

Correct
Correct is more important than efficient. Listing 1 shows a typical implementation of a correct, but inefficient, generator.

Let's see why this is correct. First, the synchronized(lock) blocks synchronized access to the listeners' list. It is very important that only the clone step of send is synchronized. This is because completing a send step may require arbitrary adds or removes. If these adds or removes happen from a different thread compared to the send, they would deadlock if send(Event) is synchronized. To avoid this problem, we copy the listeners list before notifying them, thus eliminating the resource contention. It is also important that we do not use the synchronized keyword in front of the add, remove, and clone methods. This is because using synchronized in front of a method uses the object for mutually exclusive access to the methods. Since you have no control over how the DefaultGenerator will be used, it's pretty easy to set up a deadlock situation by having this public mutex locked by something else. By sticking to an internal private object for a lock, we know we're the only ones who affect it.

Safety pays in correctness (which is a good thing), but it suffers from some serious inefficiencies:

1.  The listeners list is cloned on every send. Most of the time, nobody changes the listeners during a send, so the clone does not usually matter.
2.  An Iterator is created on every send. This is another object to create and discard. Using a (pre JDK 1.5) iterator also requires runtime safety checks while going through the List.
3.  An Event is passed to every send. Most of the time, nobody is listening to the generator, so that event usually just lands in the garbage pile.

And Efficient
Sometimes correctness costs efficiency, but we are lucky here, because we can have both (see Listing 2).

To use this DefaultGenerator, we would write:

class MyGenerator
          extends DefaultGenerator {
       void send() {
             if (listening()) send(new Event());
    }
}
}

There is more code, but what have we gained? This implementation is also correct, but look at send(), listening() and send(Event): no synchronization, no copies, no type-casts, and we only create an Event if (almost always - see sidebar) we have listeners to receive it. Instead of duplicating the listener list every time a send happens, we make copies when adding and removing from the listeners array. This works because object reference assignment is an atomic action. We use a plain old array because this eliminates unnecessary runtime type casts and the iterator overhead.

We have a generator that is still safe, but faster than the naïve safe solution. But it's exactly the kind of code that is easy to get wrong. Why would we want to rewrite something a bunch of times anyway? JDK 1.5 helps us with the use of generics. Instead of using the above pattern again and again for each kind of event, we can write it once and be done. An implementation is given in the resources.

With the generics at hand, you can stop worrying about making correct and fast generators and just use them. For example, if you wanted to a DateGenerator that sends the current Date on every tick(), a listener that printed out the date, and some main code to put them together:

class DateGenerator
extends DefaultGenerator < Date > {
    public void tick() {
          if (listening()) send(new Date());
    }
}

class DateListener implements Listener < Date > {
    public void receive(Generator < Date > generator , Date date) {
       System.out.println(date);
    }
}

public class Main {
    public static void main(String[] args)
    {
          DateGenerator generator = new DateGenerator();
       DateListener listener = new DateListener();

       generator.addListener(listener);
       generator.tick();
    }
}