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)
Posts
6 comments:
Tom, Today is CDO Releng day. Nevertheless, reading your article while waiting for the builds made my mood a lot brighter :P I'm looking forward to play with your results!
> Builtin databinding support (e.g.
> a Viewer could direclty implement
> the IObservableValue interface)
I would argue against this kind of coupling.
It creates unnecessary dependency on data binding and hard as it might be to imagine, there are still people out there who either prefer to use another data binding technology or use manual labor to do their own hand crafted MVC magic...
What we need is some kind of Event-System when it comes to change notifications (add/remove/delete/move/...) and we could naturally invent our own system which the user has to implement but why not use the one from databinding? The dependency you get is org.eclipse.core.databinding and org.eclipse.equinox.common which is IMHO acceptable.
From a user point of view it he should not care whether he has to implement the a event-system defined by the viewers or by core.databinding with the advantage that it is very likely that an implementation for Eclipse-Databinding already exists whereas if we implement our own API he always has to write his own.
Hey Tom,
Sounds great that you know all about your stuff! Its intriguing when you speak to someone who knows what they speak about, as oppose to reciting it from someone else they learned from. I can see you are very experienced and with your credentials it is quite obvious that you will make it far in life, or have already made it far in life :)
Using generics should be a strategic decision on the eclipse rcp level. Does anyone know if there will be release of eclipse rcp using generics? I would really like to see this for 4.0. Viewers and databinding really long out for generics with constructors like WritableValue(Object defaultValue, java.lang.class) ;-)
E4 will use generics + annotations at the core platform level - whether libraries like JFace and Databinding will use generic hasn't been discussed.
For JFace I have the indent to rewrite it for E4 (see bug 260451) and BTW my UFaceKit project provides you with generified Viewers already today though they don't have the same feature yet
Post a Comment