Order of execution for event listeners..??

Question

Hi there,
Looking at the JDK source, I see that all classes that generate events, iterate through the listeners in reverse order. What is more, they start at size - 2. I am first, confused as to why it goes in this direction, and second, why size - 2 is used. Does the last added one not get called?
As for reverse order, the problem I see with this is if a class that implements a listener in one way, then you want to add a listener, but your listener code depends on something being done within the first listener. For example, I created a simple file selection component. On the left is all files. On the right is the selected files. The component works fine. You can dbl-click a file to move it, or click the > or >> (or < or <<) to move selected files or ALL files in one direction or the other. The problem is, my component implements the ActionListener of the > and >> buttons. I made it public so that classes using this component could also add listeners. The main reason is, in the case of a "wizad", you do NOT want the NEXT button to be enabled until at least one selected file is in the right list box. So, when I add the listener, the component listener does NOT get called before my newly added listener. That listener does the job of moving the file and redisplaying the list of all files and selected files. But since my listener gets called first, that is not done, therefore the "selected" files list is NOT yet updated based on the button clicked. I am guessing that this occurs because of the reverse execution of listeners, and my listener is added after the component listener.
So, is there any way to reverse this without having to reimplement the list myself? I'd hate to extend JButton just to handle executing listeners in the order they are added. Seems silly to me that this is not at least an optional boolean choice to indicate the direction to execute listeners, but I sure would love to know why Sun has gone this direction.
Thanks.

Answer 1

Thanks for the reply.
That seems very odd to me, that it puts two entries per one listener. So let me ask you this, is this so that it can store the listeners in a list, but also store the type of listener? While at first this seems an odd way to use a list, I have come across several times when I wish I could store two objects in the list as one. I thus have created an inner class taking the two objects (usually a String for a "key" and an object), and then stored that in the list. The reson is, I want to store MORE than one of the same type, so a Set is out of the question, but a list only adds one object. I wish there was a class that allowed multiple values stored under the same key. I guess this would be easy enough to create, but it seems like something so often used that the JDK would have this in it already. Unless I am mistaken, I have not seen any Collection implementec class that can have multiple keys, and each key can have multiple values. Have you? So, I take it, just to verify, that the reason for storing the class type, then the actual instance is just this reason..to figure out the type it is, then the actual object that implements it (the reference to it).
Thanks.