This week's giveaway is in the Spring forum.
We're giving away four copies of REST with Spring (video course) and have Eugen Paraschiv on-line!
See this thread for details.
The moose likes Swing / AWT / SWT and the fly likes Listening to model changes with PropertyChangeEvent - and breaking your Swing app? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of REST with Spring (video course) this week in the Spring forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Listening to model changes with PropertyChangeEvent - and breaking your Swing app?" Watch "Listening to model changes with PropertyChangeEvent - and breaking your Swing app?" New topic

Listening to model changes with PropertyChangeEvent - and breaking your Swing app?

Janne Mattila
Ranch Hand

Joined: Jan 10, 2005
Posts: 32
I'm looking for a good Swing application architecture. One pattern is see mentioned is separating your Swing UI from model (the core of your application), and then listening to model property changes with propertychangelisteners. There might be additional controller-type layer between or beansbinding in use, but the main idea is:

One page about this pattern:

This is a popular pattern, right? Isn't it also fundamentally broken?

- you start up with binding a number of your model beans to Swing components with
1) firing PropertyChangeEvents from the relevant model beans
2) creating PropertyChangeListeners (either in Swing view or controller) that listen to those events and update Swing components accordingly
- your model beans are now glazed with property firing. There's n properties that fire PropertyChangeEvents when they are updated. No one can really practically tell when they call, which property events will fire as a result (this will also change in time when foo() and other model internals get updated.....and caller of cant and shouldnt be aware of the internals)
- all is well as long as, .bar(), .baz() etc are all called in EDT
- at a later point someone adds a feature which takes a long time to run. A new thread is created and SomeModelService.dodo() is called in that thread, outside of EDT
- as a result some PropertyChangeEvents are fired and listeners update the Swing components - still outside of EDT - and your code is broken and can for example lockup

By a superquick glance it looks like is broken too - if someone changes TextElementModel outside of EDT, its not good.

a) am I understanding this correctly?
b) isn't this kind of a big deal? As in, probably majority of code which uses this popular pattern, is broken or ready to be broken by updates very easily?
c) how to manage this problem?

For c) I am think about not using binding to model at all, or firing my model PropertyChangeEvents using SwingUtilities.invokeLater() - not too pretty but if I can add firing code with aspects ( this should not pollute my model too much...
K. Tsang

Joined: Sep 13, 2007
Posts: 3059

Hello Janne,

When most people talk about Swing apps they often refer to the MVC design pattern - separating the model and view and controller. Yet Swing API is kinda designed using MVC pattern called delegate-view. Delegate here means model+controller.

Using a JTable as example. Say you have a view class and a table model class. Now the table model class clearly represents the model. But is it also the controller? Sure. When you trigger those fireXXX methods from the table model class, you are controlling the view output.

Also once you have a Swing component open your app is inside the event dispatching thread (EDT). And this means single threaded or the EDT can only run one thread at a time.

Now I'm not sure if the MVC is broken or any other pattern is broken. But most of the time by the time you are done, some form of the MVC pattern is used directly or indirectly.

When I did my SCJD assignment, I could have said I used MVC but even myself am not sure.

K. Tsang JavaRanch SCJP5 SCJD OCPJP7 OCPWCD5 OCPBCD5 OCPWSD5 OCMJEA5 part 1 part 2/3
I agree. Here's the link:
subject: Listening to model changes with PropertyChangeEvent - and breaking your Swing app?
jQuery in Action, 3rd edition