Eclipse Community Forums: EMF » Binary compatibility of EMF models

Home » Modeling » EMF » Binary compatibility of EMF models(Extending an EMF model which comes from another binary w.r.t. feature id.)

Show: Today's Messages :: Show Polls :: Message Navigator

Binary compatibility of EMF models [message #1850731]

Tue, 15 March 2022 16:56

Marcus Höpfner

Messages: 56
Registered: February 2014

Member

Hi,

there is a so called core EMF model in our software.
In the package CorePackage there is an integer constant CORE...FEATURE_COUNT.
Another plugin is consuming the core plugin and extends this EMF model by extending EClasses.

If we add features in the CorePackage to existing EClasses the plugins become binary incompatible since integers are inlined.

Basically in the source code it says:
in CorePackage ... CORE...FEATURE_COUNT = 42.
in the using plugin:
UsingPackage ... SOME_FEATURE = CorePackage.CORE...FEATURE_COUNT + 1.
(which is 43)

After we add a new feature it says:
in CorePackage ... CORE...FEATURE_COUNT = 43.
in the using plugin still (of course):
UsingPackage ... SOME_FEATURE = CorePackage.CORE...FEATURE_COUNT + 1. (which is 44 now)

BUT in the class file it says something like this (don't nail me on the syntax :) )
Due to inlining:
CorePackage ... CORE...FEATURE_COUNT = 43
UsingPackage ... SOME_FEATURE = 43.

This leads to a stackoverflow error when loading and unloading a resource since eIsSet in an iteration for all features (feature ID are used).

Is there any other solution than re-compile the using plugin?
Anything to overcome this?

Thanks,
Marcus

Report message to a moderator

Re: Binary compatibility of EMF models [message #1850739 is a reply to message #1850731]

Tue, 15 March 2022 17:58

Ed Merks

Messages: 33143
Registered: July 2009

Senior Member

You could try in the GenModel setting the Model-> Binary Compatible Reflective Methods to true in the derived model.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Binary compatibility of EMF models [message #1850746 is a reply to message #1850739]

Tue, 15 March 2022 20:15

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

Ed Merks has often observed that extending Ecore is a really bad idea. It can cause some really subtle problems when Ecore evolves ever so slightly.

If you do choose to extend Ecore your extension is tightly coupled and so should be in version lock-step with EMF to avoid precisely this kind of problem. You should really set your MANIFEST.MF bounds to enforce this. However the old Classic Eclipse OCL extends Ecore and is not tightly coupled in this way so for many purposes it can work since Ecore.ecore changes are very rare or at least trivial.

I'm not convinced by your summary of your example since while the generated code uses a mix of constants, the generator synthesizes arithmetic between constants. This arithmetic should be evaluated at load time not compile time so the live 'constant' values should be consistent. A problem should only arise if you persist the result of the arithmetic in an unwise way.

(Just possibly you are suffering metamodel schizophrenia with a mix of old and new Core constants.)

Regards

Ed Willink

Report message to a moderator

Re: Binary compatibility of EMF models [message #1850752 is a reply to message #1850746]

Wed, 16 March 2022 06:11

Ed Merks

Messages: 33143
Registered: July 2009

Senior Member

Ed,

This topic is not about extending Ecore, it is about extending some other model, which is of course common practice. There was no attempt to convince you of anything but rather an outline of how the feature constants are actually generated in the package interface and how these are actually used in the generated reflective methods. It's implemented like this so that EObjejct.eGet performs faster than HashMap.get but has the drawback that derived models need to be recompiled, exactly as Marcus has observed.

With the suggested property set, the generated implementation class has a generated constant like this:

  private static final int EOFFSET_CORRECTION = XyzPackage.Literals.ABC.getFeatureID(XyzPackage.Literals.ABC__FEATURE)  - XyzPackage.ABC__FEATURE;

which dynamically evaluates the offset between the actual computed feature ID and the static constant feature ID. That value is then used in the generated methods to "correct" the static value, e.g., like this:

  public Object eGet(int featureID, boolean resolve, boolean coreType)
  {
    switch (featureID - EOFFSET_CORRECTION)
    {

Please try to keep your followup observations focused on the topic rather than on tangential topics or potential diseases.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Binary compatibility of EMF models [message #1850768 is a reply to message #1850752]

Wed, 16 March 2022 13:54

Marcus Höpfner

Messages: 56
Registered: February 2014

Member

Hi Ed,

thanks. I'll try it out.
Page 650 of 680 in the EMF book. How should I have found this so close to the end :)

Report message to a moderator

Re: Binary compatibility of EMF models [message #1850804 is a reply to message #1850768]

Thu, 17 March 2022 10:19

Marcus Höpfner

Messages: 56
Registered: February 2014

Member

Works perfectly.
In the EMF book it says, there might be slight performance impact.
But IMHO this is really negligible.
It is just a one time integer calculation of EOFFSET_CORRECTION .

So for me this is closed. Thanks.

Report message to a moderator

Previous Topic:	Generating updated feature description
Next Topic:	How to create UMLPackage object using ResourceSet?Or how to convert EPackage object to UMLPackage?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu May 02 09:24:07 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter