Java Swing: keeping the event handling maintanable

Question

In my current project we are using for our Swing client the following patterns:

Business Object (POJO) <--> (mapping) <--> Presentation Model (POJO with property change support) <--> (binding) <--> view components

Everything is fine and works the way we are expecting them to behave.

BUT, we encouter those problems when view begin to grow:

1. Many events are fired, resulting in cascading events. One update on a field may result in dozens of subsequent property update
2. When dialog complexity grows, the number of listeners grows as well, and the code begin to be messy and hard to understand.

---

Edit after first answer:

• We don't fire event if there is no change on value.
• We don't add listener if we have no need for them.

We have screen with very complexes rules and with a need for notification from other related panels. So we have a lots of useful listeners and a single user change can triggers many underlying events.

The idea about binding the presentation model with the business model is not so good for us: we perform some code in the mapping process.

---

I'm looking for guides, advices, best practices, etc about building maintainable Swing application, especially for the event management side.

Answer 1

There are many ways of reducing the number of events being sent.

1. Don't propagate an event when there is no change. A typical example for this one ios the idiomatic way of writing a setter triggering a PropertyChangeEvent (see below) but it is the case for all kind of events you fire by hand.

    public void setMyField(Object newValue) {
        Object oldValue = myField;
            if((oldValue==null && newValue!=null) || (oldValue!=null && !oldValue.equals(newValue))) {
                myField = newValue;
                propertyChangeSupport.firePropertyChange("myField", oldValue, newValue);
            }
        }
    }

2. Only register as event listener when you start to be interested in, and unregister as soon as you stop being interested in. Indeed, being a listener, even if it is for no action, forces the JVm to call the various methods used for event propagation. Not being a listener will avoid all those calls, and make the application by far simpler.

3. Consider replacing your POJO to increased POJO mapping by direct instanciation of increased POJO. or, to say things simpler : make your POJO authentical java beans with PropertyChangeEvent handling abilities. To allow them to be easily persisted, an easy solution is, once "rehydrated", or loaded from the persistence layer, add a persistence updater mechanism as PropertyChangeListener. This way, when a POJO is updated, the persistence layer gets notified, and updates the object in DB transparently.

All these are rather simple advices, requiring only a great dose of discpline, to ensure events are fired only at the right time, and for the right listeners.

Answer 2

I suggest a single event action per model. Don't try breaking it down to fields with the hopeless ProtpertyChangeListener. Use ChangeListener or your own equivalent. (Honestly, the event argument is not helpful.) Perhaps change the 'property' type to be a listenable object, rather than listening to the composite object.

Answer 3

The EventListenerList scheme used by most Swing components is fairly lightweight. Be sure to profile the code before deciding on a new architecture. In addition to the usual choices, another interesting approach to monitoring event traffic is suggested by this EventQueue subclass example.