Community
Participate
Working Groups
Just noticed that the jface.util.ListenerList has been deprecated in favor of a new core.commands.util.ListenerList. If the JFace class is to be deprecated, wouldn't this be a good time for clients to start using a common runtime ListenerList instead of introducing new API in another package? It seems in bug #94156 that we are close to having an API ListenerList supported by the runtiem plugin. This does mean that ListenerList would have to be in the "approved runtime classes" that JFace can use.
Nick: For consideration when the runtime split thing happens.
The runtime ListenerList API class is now available. It is found in org.eclipse.equinox.common, which encapsulates almost all of JFace's external dependencies. Note that the runtime ListenerList provides the option of comparing listeners using equality or identity, and that it uses copy on write to ensure thread safety. I.e., it will be slower to modify than the current commands ListenerList, but faster to access. This trade-off makes sense for listener lists that are infrequently changed but frequently used.
I have opened Bug 117519, which covers some missing API from org.eclipse.core.runtime.ListenerList. There is now EventManager, which is a convenience superclass for handling listeners. ListenerList in org.eclipse.core.commands.util is now deprecated, and should be removed before 3.2 ships. All classes in the workbench have been switched to using EventManager or org.eclipse.core.runtime.ListenerList.
Verified in I20051213-0010. There are a couple of issues outstanding: the clear() method needs to be removed from the subclasses, as it's now generally available in the superclass; and the ListenerList in org.eclipse.core.commands needs to be deleted (waiting for others to finish adapting).
*** Bug 91598 has been marked as a duplicate of this bug. ***