Java – When to use EventListenerList instead of a general collection of listeners

eventsjavaswing

When I learned how to fire events in Java, I became familiar with EventListenerList. When I create my own listeners, I write the listener so it extends EventListener, I store them in an EventListenerList, and my fire method would go through the event listeners like this:

protected void fireChangeOccurred(Change change) {
    Object[] listeners = listenerList.getListenerList();
    for (int i = listeners.length-2; i>=0; i-=2) {
        if (listeners[i]==ChangeListener.class) {
            ((ChangeListener)listeners[i+1]).changeOccurred(change);
        }
    }
}

Now I'm reviewing code that simply puts listeners into a HashMap (could be any collection), the listener interface does not extend EventListener, and the fire method looks like this:

protected void fireChangeOccurred(Change change) {
    for (ChangeListener listener : listeners) {
        listener.changeOccurred(change);
    }
}

What are the advantages of using EventListenerList instead of just maintaining my own list of listeners? Does it really only matter if the listeners are in a Swing component – does it matter for the Event Dispatch Thread?

Best Answer

EventListenerList has a method, getListeners(Class<T> t), specifically for the case where you are only interested in one event type.

Here's an example of how to use it:

protected void fireChangeOccurred(Change change) {
    for (ChangeListener listener:
         listenerList.getListeners(ChangeListener.class)) {
            listener.stateChanged(new ChangeEvent(this));
    }
}

If you choose to maintain your own collection of listeners, I recommend a CopyOnWriteArrayList.

Related Solutions

Java – Iterating through a Collection, avoiding ConcurrentModificationException when removing objects in a loop

Iterator.remove() is safe, you can use it like this:

List<String> list = new ArrayList<>();

// This is a clever way to create the iterator and call iterator.hasNext() like
// you would do in a while-loop. It would be the same as doing:
//     Iterator<String> iterator = list.iterator();
//     while (iterator.hasNext()) {
for (Iterator<String> iterator = list.iterator(); iterator.hasNext();) {
    String string = iterator.next();
    if (string.isEmpty()) {
        // Remove the current element from the iterator and the list.
        iterator.remove();
    }
}

Note that Iterator.remove() is the only safe way to modify a collection during iteration; the behavior is unspecified if the underlying collection is modified in any other way while the iteration is in progress.

Source: docs.oracle > The Collection Interface

And similarly, if you have a ListIterator and want to add items, you can use ListIterator#add, for the same reason you can use Iterator#remove — it's designed to allow it.

In your case you tried to remove from a list, but the same restriction applies if trying to put into a Map while iterating its content.

Java – a serialVersionUID and why should I use it

The docs for java.io.Serializable are probably about as good an explanation as you'll get:

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named serialVersionUID that must be static, final, and of type long:

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class — serialVersionUID fields are not useful as inherited members.

Best Answer

Related Solutions

Java – Iterating through a Collection, avoiding ConcurrentModificationException when removing objects in a loop

Java – a serialVersionUID and why should I use it

Related Topic