Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EMF/EMF 2.5/Minimal EObject Implementation"

< EMF
(New page: A planned feature of EMF 2.5, [https://bugs.eclipse.org/bugs/show_bug.cgi?id=252501 bug 252501], adds a new base EObject implementation and adopts it in Ecore. This feature first appears i...)
 
(The Implementation)
 
(3 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
== The Implementation ==
 
== The Implementation ==
  
The new implementation, <tt>MinimalEObjectImpl</tt>, reduces the memory overhead of <tt>EObject</tt> 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, <tt>MinimalEObjectImpl.Container</tt>, which adds an <tt>eContainer</tt> 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:
+
The new implementation, <tt>MinimalEObjectImpl</tt>, reduces the memory overhead of <tt>EObject</tt> by storing all of its data in a single, minimally sized array. This approach comes with a performance trade-off. The class also includes several inner classes, which add separate fields for the most frequently used items in particular scenarios. In particular, <tt>MinimalEObjectImpl.Container</tt>, which adds an <tt>eContainer</tt> 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.MinimalEObjectImpl$Container" and regenerate their code:
  
 
[[Image:MinimalEObjectImpl.png]]
 
[[Image:MinimalEObjectImpl.png]]
Line 9: Line 9:
 
== Ecore Adoption and Downstream Impact ==
 
== 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 <tt>eContainerFeatureID</tt> 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 <tt>eContainerFeatureID()</tt> method invocations. Additionally, any hand-written code that makes reference to this (or other fields that aren't in <tt>MinimalEObject.Container</tt>) will need to be manually updated to use the corresponding methods, instead.
+
The Ecore metamodel 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 <tt>eContainerFeatureID</tt> 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 <tt>eContainerFeatureID()</tt> method invocations. Additionally, any hand-written code that makes reference to this field (or other fields that aren't in <tt>MinimalEObjectImpl.Container</tt>) will need to be manually updated to use the corresponding methods, instead.
 +
 
 +
[[Category:Modeling]] [[Category:EMF]]

Latest revision as of 08:32, 5 August 2009

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 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.MinimalEObjectImpl$Container" and regenerate their code:

MinimalEObjectImpl.png

Ecore Adoption and Downstream Impact

The Ecore metamodel 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 field (or other fields that aren't in MinimalEObjectImpl.Container) will need to be manually updated to use the corresponding methods, instead.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.