Eventlistenerlist Firing Order

EventListenerList firing order

Since the documentation for JSlider and JComponent etc don't mention the order of listener notification, I would hesitate to rely on it, at least without thorough testing on each subsequent version of the JRE.

If you really need to rely on the order, consider setting up a chain of listeners, ie Listener one will notify listener two etc.

Order of listeners in Java

Here is a nice article explaining the absence of listener notification order in swing:
Swing in a better world

Why is EventListenerList traversed backwards in fireFooXXX()?

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.

Is it possible to find event fire chain in java?

See the class EventQueue. This class has all what you need, including the origin event (mouse or key event) for your selection event.

What is the order of fired events in a combobox ItemListener

In general, the order is not specified. In particular, the combo selection and text display is irrelevant to the underlying Document state. If the user elects to continue editing, simply restore the modified Document to the text area.

Why does fireTableChanged() on AbstractTableModel notify listeners last to first?

I don't think there is a real reason for it.

Maybe they wanted extra-safety in case a listener is removes itself from the list of listeners while the event is fired (i.e. while we are still iterating over the listeners-list).

Although this would not really be necessary as the listenerList is copy-on-write...

JPanel with anonymous EventListener - why doesn't GC destroy listener?

The abstract parent, JMapController, holds a reference to the JMapViewer passed there by the DefaultMapController constructor:

public DefaultMapController(JMapViewer map) {
    super(map);
}

Addendum: The map reference held by the controller is used to (selectively) add up to three controller references to the map's EventListenerList, discussed here. Any one of these would preclude GC. At least one salutary design benefit is that a concrete JMapController need only implement available interfaces.

As suggested in this MVC outline, it would be unusual to give the view a reference to the controller. In contrast, there's nothing wrong with letting the controller register as a listener to the view, as suggested here.

Note that only the no-argument JMapViewer constructor installs a DefaultMapController. You can use the alternate constructor, as noted in comments at line 57-59 in revision 29113 of Demo.java. A complete example is examined here.

How to fire JSlider change listener?

Assuming you want to notify listeners of the slider, you would use this:

    ChangeEvent ce = new ChangeEvent(slider);
    for(ChangeListener cl : slider.getChangeListeners()){
        cl.stateChanged(ce);
    }

You shouldn't need to fire the change event directly unless you're extending the class and adding some new funky functionality. In that case, the fireStateChanged() method is protected, so you should have access.

---

Related Topics