EMF/EMF 2.5/Minimal EObject Implementation

A planned feature of EMF 2.5, bug 252501, adds a new base EObject implementation and adopts it in Ecore. This feature first appears in the I200901201800 integration build. For those following only the milestone builds, it will appear first in M5.

The Implementation

The new implementation, MinimalEObjectImpl, reduces the memory overhead of EObject by storing all of its data in a single, minimally sized array. This approach comes with a performance trade-off. The class also includes a several inner classes, which add separate fields for the most frequently used items in particular scenarios. In particular, MinimalEObjectImpl.Container, which adds an eContainer field, is the most appropriate choice for use in typical generated models. Developers who wish to adopt this base class should change the "Root Extends Class" property in their generator model to "org.eclipse.emf.ecore.impl.MinimalEObject$Container" and regenerate their code:

Ecore Adoption and Downstream Impact

The Ecore model, itself, has adopted this new base class, so any models that extend Ecore will be affected (note: this is not considered an API change because you are not supposed to be extending Ecore in your models). In particular, the eContainerFeatureID field is not present in the new base class, and previously generated code does contain references to this field. Therefore, any model that extends Ecore will need to be regenerated, to convert such field references into eContainerFeatureID() method invocations. Additionally, any hand-written code that makes reference to this (or other fields that aren't in MinimalEObject.Container) will need to be manually updated to use the corresponding methods, instead.