A Focus on Data Structures

HEAD hasn't had many changes lately for data binding because of the 3.3M3 release. But this doesn't mean that nothing has been happening. Changes have been occurring in the concurrency branch (Bug116920_investigation) for, you guessed it, concurrency. But the branch has also been used for removing provisional packages and the refactoring of some of the provisional code into API. But before I get into the other changes it's very important to us that we get as many eyes on the concurrency approach as possible. If you're a concurrency guru or just someone with a interest please read through bug 116920 and provide feedback if you have any.

The other changes that have been occurring are interesting. If you are vaguely familiar with JFace Data Binding you probably know that data binding is comprised of two parts: observables and bindings. The idea behind bindings is pretty straight forward and what you would expect from the name. They bind two entities and provides a MVC-esque flow of data to keep the 2 in sync. This is normally applied in the context of a graphical user interface in order to keep the UI in sync with a model. But there's more that needs to be implemented in order to make this synchronization and this is where observables come in. Observables are an implementation of the observer pattern and they create a common abstraction that allows for the observing of changes in an object. This all begins with IObservable but branches out into:

IObservableValue

Interface for the observing of a single value.

IObservableList

Interface for observing changes in a List. The notifications are notifications of when items are added or removed from the List. If an object being maintained in the List changes events are not fired from the IObservableList implementation.

IObservableSet

Interface for observing changes in a Set. Like IObservableList the change events are for items being added and removed from the Set.

IObservableMap

Interface for observing changes in a Map. And you guess it, same type of behavior as the previous interfaces but for a Map.

For all of the above interfaces there are default mutable, or writable, implementations.

• WritableValue


• WritableList


• WritableSet


• WritableMap

By providing these implementations we, and any consumer, can use the observable implementations for any need that arises. The need doesn't have to be for binding a widget to a model, it can be any use case that you're wanting to provide notifications for a data structure. The idea is that the abstraction should feel common and also provide building blocks, just like the Collections Framework, for application needs.

In order to drive home the idea that the core of data binding doesn't necessarily have anything to do with UI the core interfaces and implementations that are UI unaware will reside in plug-in org.eclipse.core.databinding. The project is currently named org.eclipse.jface.databinding but will soon be renamed, see bug 153630 for details.