Why traverse listener lists backwards?

[J Krugman]

Looking at Swing code I'm surprised that, invariable, when a list
of event listeners needs to be traversed, it is done from last to
first. Why is this?

Thanks,

jill

 

[xarax]

Looking at Swing code I'm surprised that, invariable, when a list
of event listeners needs to be traversed, it is done from last to
first. Why is this?

Unless the JavaDoc specifies the order in which listeners
are called, you cannot rely on the order (LIFO versus FIFO)
of calling listeners. Different vendors make provide
different implementations, and thus call the listeners in
a different order. So, do not design your listeners to
presume a certain order of calling, unless the JavaDoc
of the Swing API specifies a certain order.

 

[Jacob]

Looking at Swing code I'm surprised that, invariable, when a list
of event listeners needs to be traversed, it is done from last to
first. Why is this?

I don't know the specific case, but in general (as a pattern)
it is useful to traverse this kind of lists backwards in case
the accessed element is deleted along the way. A delete during
a traverse normally affects the remainder of the list, and a
forward iteration might easily be messed up.

As this makes assumptions about the implementation of the
underlaying structure, it is in general better to iterate over
a *copy* of the list.

 

[Tor Iver Wilhelmsen]

Looking at Swing code I'm surprised that, invariable, when a list
of event listeners needs to be traversed, it is done from last to
first. Why is this?

This allows later added listeners (that is, the developer's own
listeners) to e.g. consume the event, so that the default behaviour
can be superseded by the developer's code. If it was the other way
around, then the "standard" listeners would trigger first.