Where do you go (JFace)Viewers

The presence

Today I thought about a problem of JFace-Viewers when it comes to clever memory management like it is provided for example by CDO. CDO has a very clever memory management concept where objects are swapped out of the memory if they are not referenced in application code.

When using CDO in conjunction with JFace-Viewers this concept doesn't work because JFace-Viewers restore the model element into the TableItem/TreeItem-data-slot and so CDOs clever memory management is not working and the whole model resides in memory.

Inspired by Ed's efforts to minimize the memory footprint of EObject (see bug 252501), I started to think how we could improve on the other side of the fence. I've started today implementing a set of specialized viewer classes which makes it possible for you to take advantage of the clever memory management supplied for example by CDO.

The idea is simple. Instead of restoring the real object in the viewer the object gets translated into a key value (in case of CDO it could the a CDOID) and so CDO can free memory ASAP. The code is available from the UFaceKit-Repository because the scope of UFaceKit is also to provide higherlevel utilities for current Eclipse-Technologies beside inventing it's own high-level API.

The future

The Viewer-Concept provided by JFace for StructuredControls (Combo, List, Table, Tree, TreeTable) is one of the most used concept in Eclipse-Applications and although they are very powerful and we fixed many deficiencies we could provide much better useablility and user experience in E4.

Some of them coming to my mind are:

No Toolkit-Independence we can only target SWT like controls
Usage of Java5 generics
Multiple different APIs to achieve solve a problem
Problem with memory intensive models
(Fill in your favorite problem)

If you are a regular reader of my blog you know that in my UFaceKit-Project I've already written a JFace-Viewer like implementation for other widget toolkits (QT, Swing). I've today restarted think whether this would be a good thing for E4 in general and so I filed bug 260451.

I'd like to see Eclipse-Viewer getting a project like Eclipse-Databinding which is split into a general and toolkit specific part and integrate itself seamless into the concepts provided by Eclipse-Databinding. I'd invite all of you to take part in a renewed implementation of the viewer concept by adding yourself to bug 260451 and take part in the design discussion hopefully takeing place there.

The intial list of points I'd mentionned in the bug are:

Cross-Toolkit like Eclipse-Databinding I'd like to see Viewers getting split
a Toolkit-Neutral and Toolkit-Specific API so that implementation for e.g.
Swing, QT, ... can be created.
Better support for big model graphs (e.g. better support for CDO) (see bug
260422)
Revised inline editing
Direct-Databinding support
Builtin support Async-Programming (see bug 253777)
Support for Java5-Generics
Builtin databinding support (e.g. a Viewer could direclty implement the
IObservableValue interface)