Being Productive With Swing

Adrian Sutton

These are my notes from the technical session, “Being Productive With Swing” by Ben Galbraith. The session focussed a lot on Ben’s library that he’s creating which was a shame but there are some ideas that are worth taking away.

The techniques described below are very specific to business applications that center around forms. At the moment desktop applications are “stepping up the wow” to compete with AJAX and Swing traditionally hasn’t had this – JavaFX is likely to bring this to Swing. However, for most business applications “wow” isn’t a requirement, productivity is. In that area, no emerging platform provides material advantages over Swing with the exception of JFace and Cocoa.

JFace has some really nice abstractions which make it productive, but is hard to learn.

Cocoa has great data binding via Core Data and excellent tooling support which makes it very productive, but it’s Mac only.

For business application development, productivity is king. How quick is it to make, how easy to reuse, how cheap to maintain? Swing’s not too far from being productive but isn’t there yet. JSR296 (swing application framework) doesn’t help with productivity much because it’s really just targeted at getting started with an app, not the actual form design. JSR295 Beans Binding is a key improvement.

What’s missing from Swing? It needs to be a framework instead of just a GUI toolkit. What’s a form? How does validation work etc .

Template Pattern

There are too many ways to create a GUI which makes understanding and reuse difficult. He’s created a system to enforce a standard template. The aim is to split the code up and provide as many behavioral contracts as possible to enable reuse. (To me it looks like too much up front engineering – most of the time you don’t want to reuse GUIs, they’re task specific so what’s the point of designing every GUI for reuse?)

GUI Builders

GUIs used to be hand coded because tools weren’t good enough. Ben suggests that modern GUI tools have solved that problem and there’s no good reason to use a GUI builder and he believes he’s vastly more productive using a GUI builder. Often though, people aren’t happy about having machine generated code that they then have to maintain. The key is to keep the machine generated code completely separate:

  • Bind behaviors to components by name
  • Let the builder own all the code it develops
  • Supplement the GUI builder at runtime as needed by manually creating just the parts that are dynamic.
  • Use an abstract GUI builder plugin system.
    • Support any GUI builder
    • Support custom frameworks.

Ben then went into a particular function he’s developed that helps retrieve a component by name easily. Basic idea was taken from prototype.

The issues I see with this that Ben didn’t address:

  • How do you change GUI builders and preserve the work you’ve done? What if the GUI builder you currently use is discontinued?
  • Ben suggests you can work with a team that uses a range of different GUI builders and it’ll still work. Sounds like a nightmare to me.
  • What do you do if you don’t have access to the GUI builder that was used? How do you maintain the code?

Binding

JSR295 is very exciting. Binding is important to avoid all the code required to copy data between the GUI and the model. This code is often error prone and duplicated, particularly when parsing is required (ints, dates etc)

Opensource binding systems have been available for a while and JSR295 won’t be available for some time.

The problem with binding in Java is that most systems try to make the binding bi-directional (automatically respond to changes made in either the GUI or the model). Java doesn’t have a way to watch a variable for changes so you have to implement property change notifications which is tedious and error prone. While AOP could be used here, it’s not widely accepted and you can’t assume that you can just store the current value, make the change and send the notification – some variables need special change handling.

In most apps, there isn’t a need for bidirectional binding, it’s okay to just provide a method that tells the binding framework when changes have been made to the model (swing already has property change notifications built in so it can use them).

Simple Configuration

It’s a pain to apply common attributes like padding, bolding etc to components. Ben implemented CSS for Swing to work around this. To me CSS doesn’t apply particularly well to Swing – it’s a DSL for styling HTML, not swing. It would be better to create a DSL specifically for styling swing if you wanted to go that route, but if you’re using a GUI builder you should just use the GUI builder to do this so that it owns all the code and you can see what it actually looks like in the GUI builder. Otherwise, write the GUI by hand and just use utility functions to set up components with the default settings you need.

Ben’s framework is available from http://code.google.com/p/swing-clarity/