Archive for September, 2010

A better data binding model

If you have ever implemented a user interface, you have more likely been confronted with the problem of data binding and notification: whenever a value in your model changes, how do you update your user interface to reflect the new values?

In Java, the standard solution is to use PropertyChangeSupport and PropertyChangeListener, but I have always found this approach very cumbersome and hard to scale. In this post, I will explain why and I’ll offer what I think is a superior solution.

The problem with PropertyChangeSupport

Here are the main issues with PropertyChangeSupport:

Extreme boilerplate

Any bean or model class that wants to notify the rest of the world that its value changed needs to include the following:

public class SomeBean {
 private PropertyChangeSupport changeSupport = new PropertyChangeSupport(this);
 public void setProperty(String newValue) {
  String oldValue = property;
  property = newValue;
  changeSupport.firePropertyChange("propertyName", oldValue, newValue);
 public void addPropertyChangeListener(PropertyChangeListener l) {
 public void removePropertyChangeListener(PropertyChangeListener l) {

That’s a lot of code for something that should be very simple.

Note that this code looks like it might be a candidate for a trait (the kind you find in Fantom or Scala). A trait (or mix-in) is a class with several restrictions that other classes can “import” directly as part of their implementation. If we defined a PropertyChangeSupport trait, any class importing this trait would automatically expose the three methods defined above.

The problem is that most trait implementations impose certain restrictions on how you can specify your trait, and one of them is that they can usually not carry state (no fields). Since a property change support will usually carry at least one if not two pieces of state (the change support object and maybe the name of the property), I’m not convinced that traits would be useful here. If anything, only languages that support multiple inheritance of implementations would allow some of this boiler plate to be reduced (e.g. C++).

Extreme coupling

In order for a GUI element to update itself when a value on the model changes, it needs to add itself as a listener on that model. For example, you can imagine that if a name changes in the mode, the user interface will want to update a label and a window title. If you do the math, you will see that “n” user interface elements that need to monitor “m” model objects will result in n*m couplings. And of course, your model and your view are now very tightly coupled, which adds even more problems.

Extreme data exposure

Because Java doesn’t natively support properties, not only do you find yourself having to specify your setters manually, you also need to remember to fire the appropriate PropertyChangeEvent whenever a value changes. This is not only error prone, it also exposes you to the dilemma of deciding whether you want to fire such events for model objects that don’t directly impact the GUI at the moment (what if they do at some point in the future?).


All these considerations started bugging me quite a bit recently as I was busy working on an Eclipse plug-in. I was multiplying the number of PropertyChangeSupport objects throughout my models and mostly extending the same class over and over (if I was lucky) or just copy/pasting the code above (most of the time). I strongly disliked the amount of pollution that was beginning to invade my code and I started considering alternatives.

And then, I remembered a post that I wrote a few months ago about “local buses”. It occurred to me that if I could insert a message bus between the model and its listeners, then the two worlds would become completely decoupled. On top of that, I might be able to add some kind of property support that would hide most of the complexity.

JBus and properties

My implementation of the local bus is very small and very simple and is similar to what I described in the blog post linked above: listeners are methods and they declare themselves with a @Subscriber annotation. These methods are expected to accept one parameter which represents the class of the event they are interested in.

Here is a quick example:

public class App {
  public void event1(NotifyEvent ne) {
    System.out.println("event1: " + ne);
JBus mb = new JBus();
jb.register(new App()); NotifyEvent("notify"));

This is the first part of the plumbing. GUI elements that want to receive updates will simply declare themselves as subscribers for certain types of events (typically, PropertyChangeEvent, but it doesn’t have to be restricted to that).

The second part is to automate the publication of events as much as possible, and I ended up creating a class Property for this. Here is an example of how to use it:

public class Person {
  // A property that the GUI is interested in
  private Property<String> name;
  // A field that the GUI is not interested in
  private int age;
  public void setName(String n) {

The first thing you notice is that because they are of type Property, properties that publish events are easy to identify in the code. Additionally, properties will automatically publish events whenever their setter is invoked, which imply that 1) they need to have an instance of the message bus and 2) they need to know the name of the property that changes will be published under.

Therefore, the Property constructor looks like this:

public class Property<T> {
  public Property(JBus bus, String propertyName, Object source) { ... }

The source is optional but if you specify it, it will make it possible for events to be discriminated based on where they came from, which has several practical uses.


As soon as I converted my code to using JBus and Property, I noticed a radical decrease in boiler plate code and a dramatic increase in flexibility. Whenever a new model appears, making it publish events is trivial. Whenever I introduce a new graphic element that needs to update itself, I no longer need to find a way to locate the model object(s) it’s interested in and add itself as a listener: all I need is the name of the property.


Here are a few downsides to the JBus approach:

Bus ubiquity

In order for this approach to work, model objects and graphic user interface elements must have a pointer on the message bus used to exchange events. In effet, I am transforming an “m * n* dependency graph into an “m + n” one, with all m and n depending on the message bus. The bus is becoming the central piece on which all event entities depend.

Is this a bad thing? I’m not sure. From a design perspective, I still think that the general decoupling that results from the introduction of the bus is too flexible to ignore. From an implementation standpoing, having this kind of uber object present everywhere can be a concern but dependency injection frameworks make this a non-issue.

Another potentially interesting aspect that I haven’t explored is that you don’t need to restrict yourself to having just one instance of a bus. If certain parts of your applications are completely isolated from the others, you might want to create a specific bus just for them since this will speed up the look up and delivery of events. I’m not sure that the performance improvement would be noticeable in general, though.

The property name

While we have almost entirely decoupled models and GUI elements completely, they are still connected by two tiny pieces of information: the bus and the name of the property. The downside of this approach is that the coupling is no longer statically typed and if you ever change the name of a property, you need to make sure that all the subscribers get updated as well. I haven’t seen this as a big issue so far and you can always increase your comfort level by having these classes reference to the same string constant (thereby re-introducing a little bit of coupling).

If this is still too loosely coupled to your taste, you can always decide to have your GUI element bind itself to the Property directly. In this case, the GUI element no longer even needs to have an instance of the bus, but you are also getting dangerously close to the problem you were trying to solve in the first place.


JBus uses reflection to calculate recipients of event messages, which is probably slower than when your GUI objects add themselves as listeners of your model objects. I am planning to improve the performance of JBus in that respect (with a lot of caching since the reflection information will not change once an instance of the bus has been created) but you are also not limited to JBus. You can always implement your own concept of a software bus and make it work without any reflection at all.

In practice, my gut feeling is that the overhead caused by reflection will probably be dwarfed by the delays found in the GUI anyway, so I’m not too worried about that.

Potential improvements

While I started implementing JBus as a generic local bus framework, the fact that it’s so useful as a property change publication mechanism made me wonder if I shouldn’t provide some specialization for specific use cases, namely making special cases for PropertyChangeEvent, which is likely to be the even that is the most used.

For example, JBus allows you to publish events in certain “categories” (strings) and allowing listeners to only receive events if they have declared an interest in the type of that event *and* the fact that it was published in the same category. I noticed that it’s often convenient to publish property change events automatically assigned to the category that matches the property’s name.

Interfaces vs method listeners

The way JBus matches events to listeners is not very different than the way you do it with listeners, except that listeners defined in interfaces force you to implement the entire interface, even when you are not interested in all the lifecycle methods. The @Subscriber annotation allows you to only receive notifications for the events you are interested in.

In conclusion, data binding user interfaces to models with a message bus provides more flexibility and allows you to decouple your domain objects completely. I’m hoping that this approach will help me build user interfaces that are able to manage their consistency without as much work as the PropertyChangeSupport approach requires.

A quick guide to pull requests

It’s pretty common for projects hosted on GitHub to receive “pull requests”: requests from people who have cloned your project, made a modification to it and then asking you to merge their changes back into the main project.

There are a lot of ways you can handle these pull requests, here are some of them.

Using GitHub’s web interface

If you go to the “Fork Queue” panel of your GitHub dashboard, you will see all the pull requests that have been issued by contributors. From this page, you can apply changes directly to the specified branch, which means that you will automatically get them on your local machine next time you pull.

I rarely use the web interface because I usually want to test the changes on my machine before committing them. I also usually want a few changes to be made to the commit before merging them, such as adding comments, cleaning up indentation, etc… and I find that it’s just faster to do this myself than to request it with comments on the web interface.

Having said that, the web interface is convenient to quickly apply cosmetic commits that don’t change any code (documentation updates, space clean up, etc…).

git am

The git am command allows you apply a diff to your working directory. Every pull request comes with a corresponding patch URL that you can retrieve and apply directly. You create this URL by adding “.patch” to the address:

curl | git am

This works with regular commits as well:

curl | git am

After this, you can just push your branch.

I find this very convenient to apply patches that are coming from contributors that are sending a patch for the first time. Since I’m not sure whether this person will contribute more patches, there is no point in creating a remote branch for them yet, so this kind of one off procedure is ideal.

Merging the remote branch

This approach and the next require you to create a remote tracking branch for the user that sent you a pull request. Once you have identified in which branch they created their patch (usually master, but savvy users tend to create a specific branch to make sure that only the commits that they want will be part of the pull request), you simply create a remote tracking branch, fetch it, merge it in your own and then push:

      # add the remote branch
$ git remote add nullin git://
      # fetch it
$ git fetch nullin
      # merge it into my current branch
$ git merge kneath/error-page
      # push
$ git push origin master

Cherry picking

This is similar to the previous approach and it is recommended when the pull request contains some extra commits that you are not interested in. They might be there either because the author of the pull request wants you to merge them but you disagree, or they simply made a few mistakes and added unrelated commits to their request (this can happen if they didn’t bother creating a specific branch for the pull request).

The procedure is similar to the one above except that instead of merging the full remote branch, you just cherry pick the commits you want:

      # add the remote branch
$ git remote add nullin git://
      # fetch it
$ git fetch nullin
      # (inspect the commits on the nullin branch)
      # only pick the commits I'm interested in
$ git cherry-pick commit1
$ git cherry-pick commit2
      # push
$ git push origin master

Have I forgotten anything? How do you handle pull requests?

Commercial break

Let’s take a break from the heavy stuff and enjoy three light hearted videos:

A Kindle ad

An iPad application ad

And some dancing (watch until the end).

Interesting Chrome UI

I noticed this interesting menu in Chrome earlier.

I have expressed a few dislikes for Chrome in the past, and while I still don’t appreciate the non-standard menu, I like the innovation attempt here.