[stem-dev] Effects of enabling CDO for STEM

[Tero Parviainen <tero.parviainen@xxxxxxxxxx>]

Hi,

I've been exploring the practical consequences of CDO-enabling the STEM EMF model. I did the genmodel conversion by following the instructions in the CDO wiki (http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO), and the code is in my Github repo at http://github.com/teropa/stem/tree/cdo. 

Here are some of my main observations:

- CDO requires we use either dynamic or reflective feature delegation in EMF models. The main
  effect this has to the current application code is that direct field access cannot be used in EMF
  models. Thus, all places where fields are accessed directly in non-generated code have to be
  changed to getter/setter access (this.canonicalGraph -> getCanonicalGraph()). This requires
  quite a large amount of changes in the code, but they are for the most part simple to make.

- EMF seems to prefer identity semantics for implementing equals/hashCode, and CDO actually
  enforces this by making them final in CDOObjectImpl. There are a few cases in the STEM code
  where equals/hashCode have been overriden to use value semantics (most notably STEMTime),
  and this doesn't work with CDO. Places where these objects are tested for equality or used in
  HashMaps/HashSets would have to be changed.

- I'm not seeing any noticeable performance degradation after the CDO refactoring, but I haven't
  actually measured this. I also haven't yet used any of the distribution capabilities of CDO, so
  I cannot yet comment on how well that works.
  
Br,
Tero