JDK-4178930 : Swing models need pre- and post-listeners
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.beans
  • Affected Version:
    1.1.7,1.3.1,1.3.1_06,1.4.0,1.4.1,1.4.1_02,1.4.2,6,6u12 1.1.7,1.3.1,1.3.1_06,1.4.0,1.4.1,1.4.1_02,1.4.2,6,6u12
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS:
    solaris_2.5.1,windows_nt,windows_2000,windows_xp solaris_2.5.1,windows_nt,windows_2000,windows_xp
  • CPU: x86,sparc
  • Submitted: 1998-10-06
  • Updated: 2016-02-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Name: el35337			Date: 10/05/98

It seems like one problem with the current
Swing M/(VC) model is that there is no ordering
distinction among the listeners added to Swing
components.  This makes it very difficult to
ensure that operations are ordered properly.

For instance, with the JComboBox, it is easily
possible to have one's actionPerformed() method
called before the JComboBox has completed its
rendering cycle and put the popup menu down.  In
our application, we put up a modal dialog in response
to a change in a particular JComboBox.  Because
our actionPerformed() method is called before the
V/C has finished with its rendering, we get the
display stuck in the middle.  There is no practical
way of preventing this outcome, as even if we use
threads, there's no guarantee that we can invoke
the display of our dialog after the JComboBox has
finished putting down the popup menu.  The
SwingUtilities.invokeLater() method might help
here, but it seems very iffy at best.  If we
could add a listener with the qualification that
it was to be called after the primary gui control
had finished with its update cycle, this wouldn't
be an issue.

Similarly, there are times when one seeks to do
event filtering, such as with popup's over JLists,
or with keystrokes in a text field.  It would be
great if there was a way to get notified of an
event before the model was, so that some code
could make a go/no-go decision before the gui
did its update.  We do this with text fields
now by subclassing the text field and overriding
processKeyEvent(), but this seems very reminiscent
of the pre-JDK 1.1 model, where you had to subclass
everything to provide any sort of custom behavior.
If it were possible to interpose an event listener
before the model was changed that had the ability
to prevent further processing of the event,
it would be possible to easily impose event
filtering without having to be always subclassing
GUI components and/or models.

My briefly-thought-out idea is to have three temporal
categories for listeners, so you could add listeners
to be called before, during, and after the gui
rendering cycle.  I know this is a horrifically
big change to the code, and may thus not be feasible,
but as it stands, it is very difficult to reliably
use Swing in some circumstances because of the
loose-binding brought about by the MVC model.
(Review ID: 39994)

EVALUATION Please check out the related discussion http://forums.java.net/jive/thread.jspa?threadID=16197&start=0&tstart=0

EVALUATION Contribution forum : https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=13717

EVALUATION See also 4730055. Implementing this would allow developers to deal with this sort of issue.

EVALUATION Yes, this is actually a huge problem as some of our UIs expect to get notified before the developers listeners so that if they don't any methods that query the state of the component end up returning bogus information. It might be possible to minimize the scope of this change by mixing in a new interface: public interface ListenerOrdering { public int getOrder(); } If done in this manner the change would mostly be centered around the event listener manager classes. Swing would then define the order it adds its listeners so that it would be relatively easy to add listeners before/after the UIs need to get notified. I'm reassigning to beans as a change of this scope would likely better fit in the beans space. --- This is something that would require a lot of thought and testing. Perhaps the EvenListenerList can have a notion of adding listeners at the front or end of a list. The add<foo>Listener(Listener) method may have to be expanded to include the order (or placement) of the added listener. The Beans Spec would have to be revised to mention possible listener ordering. A similar issue that was presented by a customer was that the Events on listeners may take two different paths to a common target but there may be a dependency between the end results so that one listener must get there first. ie. ---- B -- C -- / A D \ / ------ E ---- If A fires events and B and E are listeners to A, then we may want some way to guarantee that the path A-B-C-D arrives before A-E-D. Food for thought. ###@###.### 2002-05-30 When this RFE is addressed, we should ensure that the order given to UI installed listeners remains constant, even after a UI switch. This issue came up in bug 4871932. ###@###.### 2003-06-02