Java Property Change listeners

Question

I would like to know , how the java beans property change listeners work. Do they use , EventListeners inside ? Is it good to use , property change listeners when we can do same with POJO implementation of mediator pattern . I mean performance wise ?

Thanks J

Answer 1

The advantage is in the area of coupling. mediator requires that your classes be aware of the mediator (eg by passing the mediator instance into the constructor). Mediators can be very powerful, and can definitely provide more efficient notification - but at the cost of significant complexity.

In contrast, the Observer design pattern (which JavaBeans property change listeners are an implementation of) are much easier to implement. But they can have interesting emergent behavior in complex systems.

For many situations, Observer is more than adequate (especially in the areas that JavaBeans tend to be used). In other situations, it is nowhere near adequate - a good example is in event propagation in the Glazed Lists library . They wound up having to use an EventPublisher (which is a mediator) to optimize event notification order, and ensure that dependencies are met before events propagate.

So, the answer to your question is that this is not a matter of POJOs vs JavaBeans. It's a matter of which design pattern (Observer or Mediator) makes the most sense for a given use case. Both patterns focus on decoupling parts of the system from each other. And both patterns have situations where they are appropriate. For a huge number of situations, Observer is just fine - and is really, really easy to write.

I should also mention that the use of intermediate event objects is common in both Observer and Mediator implementations, so that's kind of a side issue. But modern VMs are really efficient at dealing with short lived objects like that - so it's really a non issue.

Answer 2

The code you look for is in java.beans.PropertyChangeSupport . You use it like this:

protected transient PropertyChangeSupport changeSupport = new PropertyChangeSupport (this);

public void addPropertyChangeListener (String propertyName, PropertyChangeListener listener)
{
    changeSupport.addPropertyChangeListener (propertyName, listener);
}

public void removePropertyChangeListener (String propertyName, PropertyChangeListener listener)
{
    changeSupport.removePropertyChangeListener (propertyName, listener);
}

public void firePropertyChange (String propertyName, BigDecimal oldValue, BigDecimal newValue)
{
    if (oldValue != null && newValue != null && oldValue.compareTo (newValue) == 0) {
        return;
    }
    changeSupport.firePropertyChange(new PropertyChangeEvent(this, propertyName,
                                               oldValue, newValue));

}

The main advantage of using this API is that everyone is familiar with it. The main disadvantage is that the Beans API is pretty old, cumbersome from todays point of view and very limiting.

For example, you need the name of a property in many places. This either means you must copy a string (which breaks if you rename the property) or you must manually define a String constant for every field which is tedious.

The implementation itself is pretty fast and follows the Observer design pattern. Of course, there are other ways to implement this. The price would be that this is no longer a bean since it doesn't follow the API. Hence, you can't use your object in many frameworks without additional glue code.