Enhance Listeners in Swing (Ordered, WeakReferences)
Since there are no way of defining the relative ordering of the listeners in Swing (the order is "undefined") it is hard to "snatch" events from a component that you can't, or don't want to, subclass. You might also want to be able to "pick up" events that haven't been caught (consumed) by a component and thus would like to register yourself last in the listener list chain.
I suggest that API for defining the ordered listeners be added. If using the old API (today) the listeners would be added at level "NORMAL". Some other standard levels could easily be defined. Maybe even with the possibility to “listen to the listener list”, mostly for debugging maybe.
I know that you can never be "guaranteed" of being the first listener since there might be someone else registering a listener with an even lower order/level. This would practically not be a problem though, IMO.
This would compensate for the lack of pre- and post handling in Java, if you know what I mean.
On the same subject I would also want to add support for optionally adding the listeners wrapped in WeakReferences. This is good for defying memory leaks. I alway use this technique when I roll my own listener handling (which I almost always do, since I find the Swing one rather limited;) ).
It is important to write in the JavaDoc, in bold, that it should be used when the listeners haven't got any other strong reference holing on to it. For instance anonymous inner classes can't be added as weak references since they would go away almost immediately.
addXXXListener(XXXListener listener, int level, boolean asWeakReference);
A version without level must be there as well of course.
Implementing this would actually make using swing easier, since memory leaks can be avoided (for many cases anyway) and the confusing "undefined" order of listener notification can be remedied.
Since adding this to every Swing class would make a lot of code bloating, I suggest putting all logic in a standard EventHandler that is subclassable to implements all the different types of Listeners, possibly via reflection.Having a separate class that are handling all the logic would make it a snap, and without code bloat, to add thing such as listeners to the listener list and logging.