RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Beans Binding: A Java Data-Binding Solution with a Serious Problem

Data binding simplifies how you sync a data object's properties with their visual representations, and Beans Binding for Java (JSR 295) aims to deliver a default data-binding specification for the Java platform. Find out how to use Beans Binding and work around its onerous overhead.

n the past couple of years, data binding has emerged as an important concept for GUI development in Java. Its main objective is to simplify the task of syncing a data object's properties with their visual representations on the screen (text fields, tables, combo boxes, etc). JSR 295 (Beans Binding for Java, or simply Beans Binding) aims to deliver a default data-binding specification for the Java platform. Although JSR 295 is not yet part of the official JDK, you can download the reference implementation (at the time of writing, version 1.2.1). The last version was released in November 2007, with no new updates since. Although this signifies a mature and stable code base, a few issues prevent this library from being a perfect data-binding solution (more on that later).

Following a discussion of the types of properties that make up the building blocks of Beans Binding, this article walks you through binding object properties and collections, converting data between the input type and the destination property, and adding validators. It concludes with an examination of where the Beans Binding reference implementation falls short.

Beans Binding Building Blocks
The following are the fundamental types used by Beans Binding:

  • BeanProperty: This is one of two types of properties supported by Beans Binding. It defines a disconnected property definition for a JavaBean and a straightforward path to an object's property. It can be defined as either a direct property of an object, like this:
    BeanProperty<MyPOJO, String> stringProperty = BeanProperty.create("text");

    Or as a nested property, referring to a child object's property, like this:

    BeanProperty<MyPOJO, String> stringProperty = BeanProperty.create("pojo.text");

    BeanProperty is usually the best choice when dealing with two-way binding (i.e., when a change on either the source or target object should cause a data-binding synchronization).

  • ELProperty: This is a useful property that lets you embed an EL expression directly into the property definition, which enables you to create a binding to a collection of properties, for example:
    ELProperty <Employee, String> employeeFullNameProperty = ELProperty.create("${employee.firstName} ${employee.lastName}");

    You even can put Boolean conditional statements into the property definition, for example:

    ELProperty <Employee, Boolean> isEmployeeActiveProperty = ELProperty.create("${employee.status > 0}");

    You also can use ELProperties for two-way data binding, but only if the objects contain a one-to-one property mapping expression, for example {employee.name}. For more complex expression (such as in the previous examples), you can use it for one-way data binding only (i.e., from source to target, but not the other way around).

  • UpdateStrategy: To provide you more control over your binding approach (two-way and one-way), Beans Binding uses the UpdateStrategy enum to define each type of binding being created. UpdateStrategy has the following three values, which are well explained in the source code itself:
    An update strategy where the {@code AutoBinding} tries to sync the target from the source only once, at bind time.
    An update strategy where the {@code AutoBinding} tries to keep the target in sync with the source.
    An update strategy where the {@code AutoBinding} tries to keep both the source and target in sync with each other.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date