Is UI data binding in Java more trouble than it is worth?

Question

I've spent some time recently learning and attempting to use various Java data-binding tools such as JGoodies, GlazedLists, JSR-295, etc. The problems that I've been trying to solve are not that difficult, however the amount of code I've had to write in support of the binding process heavily outweighs any simplifications it provides.

I've found that the tools provided don't lend themselves to anything other than trivial composition and extension (GlazedLists in particular provides a great set of tools, but is far too complicated a system to extend).

I really like the idea of data-binding, however it seems to be deeply flawed as it stands. Am I missing something?

Gpo

certainly an interesting topic, but not really an answerable question, IMO :-) Have used and liked JGoodies (what's it's state, any evolution recently?) and jsr-295 (had been promising, but abandoned for years), both great in reducing the perceived complextity of binding ui elements. Wouldn't group GlazedLists into that league, it's not really about binding. Seeing your evalutation "amount I have to write for xx binding support heavily outweighs any simplification", then my first reaction is: then your context is too trivial to profit from any binding framework ;-) My cents, only – Bullpen

kleopatra: There has always been a huge disconnect in the Java community in context of such specs and approaches. J2EE very much comes to mind as well. timpatt: These specs are about component oriented development and require tooling support. How do you think VisualStudio works? – Shortcoming

@Shortcoming He mentioned only 1 spec. It does not require tooling support (although it might be nice to have some). It's main problem is: it's dead. JGoodies is doing fine (but isn't a spec) – Flake

@jens: "I really like the idea of data-binding, however it seems to be deeply flawed as it stands. Am I missing something?" I addressed his question here and in my answer: Why data-binding? – Shortcoming

Answer 1

All my presentations regarding desktop patterns and data bindings contain a strong warning regarding the problems developers face with automatic data binding. And I suggested to consider using a desktop pattern like MVP that is quite easy to use and does not need a binding.

The problems with binding are the many implicit operations; these help but are difficult to understand if something unexpected happens, and only a few developers can debug and solve problems in a third-party binding chain.

But during that past three years less programmers in the projects I worked in actually faced problems. And so I tend to say that binding is not such a big problem any more.

Squalid

Answer 2

If your app is trivial you it really doesn't matter if you do binding or if you write your listeners one by one.

If you app has made progress for some man months, introducing binding after the fact will cause some pain. The same is true for pretty much every (helpful) technology. Large amounts of the pain might come from the mess you took for granted before.

If you use binding correctly you might gain complete separation of gui and gui behavior. This in turn means

• you can test you presentation model (the stuff you bind your components to) without swing, without EDT, just with plain unit tests.
• you can test you binding with simple test involving only very few Swing Components

If you try to reach the same without a binding framework you'll end up writing your own binding framework.

There is a serious problem though IMHO about binding in the java world. It forces you to write getters + setter with PropertyChangeSupport, which is tedious and error prone. I don't see a realistic way to fix it in Java, but other languages (think Scala) offer interesting oportunities here. See my last blog post if you are interested: http://blog.schauderhaft.de/2011/05/01/binding-scala-objects-to-swing-components/

Flake

You've hit on a point I failed to make above; and that is that the presentation model idea (and the nice way it allows unit testing ui logic in particular) is the reason I began looking into binding frameworks in the first place. I think you're right re: the problem being Java, too. I'm considering moving the binding code to a more expressive language (groovy?)... – Gpo

Have a look at code.google.com/p/client-objects It does the PropertyChangeSupport for you at runtime – Heavierthanair