Thursday, March 8

Beans Binding

Hello folks,

as I have some spare time now (being on leave for two weeks), I would like to point your attention to the JSR-295 "Beans Binding" databinding framework for Swing, which seems to be near completion. Proper databinding support looks to me to become a big plus for rich client applications with Java.

The lead of the project has very recently been taken over by Shannon Hickey, who introduces himself in this forum post at He writes, the project would be "almost ready" for an initial public release.

But how exactly does a databinding framework ease the development of rich client applications? For one part, it hides the tedious work of creating listeners, binding them to widgets and having them update your Java beans behind a convenient automatism. This obviously makes the development more easy. For another part, the automatism allows GUI editors like Netbeans to actually support databinding visually. Roman Strobl (Roumen) has put together an excellent demonstration using Flash, which shows how Netbeans 6 might do the job. This stuff looks very neat, it is exactly what I was missing in Java Swing.

The Beans Databinding project is not the only effort to provide databinding in rich client applications. Specifically, there is
The article "Understanding JFace databinding in Eclipse" on developerworks compares both frameworks and shows how they are typically used. If I pull out my crystal ball and try to see the future, I think I will see the JSR-295 API survive the two others in the long run. How exactly will have to be seen as soon as a public release is out. After all, the JGoodies framework is (I guess) used in a number of projects already, so it won't go away too quickly. For the JFace databinding... I would hope that they review their framework design, comparing their goals with what the future Beans Databinding standard API can bring, and conclude that it is better to use the standard API (with some extensions possibly) instead of writing something else entirely. As it is new and not yet fixed, the chance is still there to switch to the standard API (if possible). (effjay)


Blogger Brad Reynolds said...

Disclaimer: I'm a committer on JFace Data Binding.

In Elipse 3.2 the library was experimental but we will be releasing 1.0 with Eclipse 3.3. The API will be frozen for 1.0 as of this weekend and there are quite a few consumers of it already. JFace Data Binding has been in the works for a while and it wouldn't make sense to drop it just because there's a JSR. I'm not up to date on the progress of the JSR but we're pretty happy so far with our library as it satisfies our needs and from what we can tell it satisfies the needs of others as well.

>"As it is new and not yet fixed, the chance is still there to switch to the standard API (if possible)."

I'm not sure what this means as it's not needing to be fixed (it's not broken). It's not possible for us to drop what we have as I stated previously the 1.0 API freeze is this weekend with the 1.0 release to follow.


8:40 PM  
Blogger Brad Reynolds said...

I just realized that you meant "fixed" as the API was not set in stone. It is or at least will be in a few days.

One difference though between the JSR and JFace Data Binding is that we're not just targeting the binding of beans. Our core API is bean agnostic to allow for other types of models (e.g. EMF) to be bound as well. But by default we provide bean implementation of our API.

Anyway it's going to be an interesting year. It's good that there's so much work being done on this front. In the end I think we'll all win as we'll have strong libraries for the binding of data.


9:03 PM  
Anonymous Anonymous said...

"In the end I think we'll all win as we'll have strong libraries for the binding of data."

It's too bad that the Java world is split between IBM/Eclipse and Sun/JSR.

Instead of one data-binding API, we end up with 3, 4, or who knows how many...

In an ideal world, Sun and IBM would cooperate much more than they do. Sigh.

7:39 AM  

Post a Comment

<< Home