Home » Modeling » EMF » Are these EMF limitations?
| Are these EMF limitations? [message #419466] |
Fri, 23 May 2008 07:01  |
 Al B
Messages: 130
Registered: July 2009 |
Senior Member |
|
|
For our new product release, we have to use the 3 flavors of EMF EClasses.
The first flavor is a static EClass, which we define in a X.ecore file and
generate using a X.genmodel that has the "dynamic" attribute set to
"false" for the EClass.
The second flavor is a dynamic EClass, which we define in a Y.ecore file
and generate using a Y.genmodel that has the "dynamic" attribute set to
"true" for the EClass. This results in no java implementation class being
generated for this EClass. Instead the values of the class's attributes
will be stored in an array.
The third flavor is a runtime EClass, which we construct at runtime by
calling EcoreFactoryImpl.createEClass(). These EClasses are also dynamic
so the class's attributes are stored in an array.
However, we ran into a problem with dynamic features created on-demand
because we couldn't use instances of our static EClasses. So, we had to
create a dynamic EClass to subclass and extend our static class. When a
new feature was demanded, we added the EAttribute to the dynamic EClass.
Unfortunately, existing instances of the EClass would be lacking storage
space for it and would cause an ArrayIndexOutOfBounds exception.
We were able to patch the implementation to avoid this by creating our own
extension of the EMF EPropertiesHolderImpl that expands the storage space
on demand. The patch is implemented as inner classes; which are created by
overriding the existing eProperties() method.
Although it is possible to change the supertypes of any EClass at runtime,
there are several cases where this will ultimately fail. The first case is
where you change the supertype of a static EClass. New instances won't
implement the new interface(s) of the supertype. The second case is where
you change the primary supertype of a dynamic, non-runtime EClass. This
will cause ClassCastExceptions during instantiation. The third case is
where you add multiple static supertypes to a dynamic non-runtime EClass.
This will cause attribute resolution failures, that sometimes manifest as
ClassCastExceptions during attribute access, and sometimes succeed with
unexpected effects.
EMF is also picky about the way you mix the three flavors of EClasses. For
example, if you build a hierarchy where a static EClass inherits from a
dynamic EClass, the generated code won't compile. Also, if you build a
hierarchy where a dynamic EClass inherits from two or more static
EClasses, the generated code won't compile.
|
|
|
| Re: Are these EMF limitations? [message #419469 is a reply to message #419466] |
Fri, 23 May 2008 11:51  |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070800060407090405020902
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
AJ,
Comments below.
AJ wrote:
> For our new product release, we have to use the 3 flavors of EMF
> EClasses.
And I though we only had vanilla!
>
> The first flavor is a static EClass, which we define in a X.ecore file
> and generate using a X.genmodel that has the "dynamic" attribute set
> to "false" for the EClass.
>
> The second flavor is a dynamic EClass, which we define in a Y.ecore
> file and generate using a Y.genmodel that has the "dynamic" attribute
> set to "true" for the EClass. This results in no java implementation
> class being generated for this EClass. Instead the values of the
> class's attributes will be stored in an array.
I wonder why you do this? It's fine of course, but usually it's nicer
to have a generated API.
>
> The third flavor is a runtime EClass, which we construct at runtime by
> calling EcoreFactoryImpl.createEClass(). These EClasses are also
> dynamic so the class's attributes are stored in an array.
>
> However, we ran into a problem with dynamic features created on-demand
> because we couldn't use instances of our static EClasses.
Of course in no case can you modify the generated models at runtime and
in no case can you modify an EClass for which instances already exist
> So, we had to create a dynamic EClass to subclass and extend our
> static class. When a new feature was demanded, we added the EAttribute
> to the dynamic EClass. Unfortunately, existing instances of the EClass
> would be lacking storage space for it and would cause an
> ArrayIndexOutOfBounds exception.
> We were able to patch the implementation to avoid this by creating our
> own extension of the EMF EPropertiesHolderImpl that expands the
> storage space on demand. The patch is implemented as inner classes;
> which are created by overriding the existing eProperties() method.
Dynamically changing an EClass sounds like kind of a bad idea.
>
> Although it is possible to change the supertypes of any EClass at
> runtime, there are several cases where this will ultimately fail. The
> first case is where you change the supertype of a static EClass. New
> instances won't implement the new interface(s) of the supertype. The
> second case is where you change the primary supertype of a dynamic,
> non-runtime EClass. This will cause ClassCastExceptions during
> instantiation. The third case is where you add multiple static
> supertypes to a dynamic non-runtime EClass. This will cause attribute
> resolution failures, that sometimes manifest as ClassCastExceptions
> during attribute access, and sometimes succeed with unexpected effects.
You really need to ensure your metadata is stable once you start
creating instances. EMF does support open content features to support
things like lax wildcards.
http://www.theserverside.com/tt/articles/article.tss?l=Bindi ngXMLJava
So that seems like a better approach.
>
> EMF is also picky about the way you mix the three flavors of EClasses.
> For example, if you build a hierarchy where a static EClass inherits
> from a dynamic EClass, the generated code won't compile. Also, if you
> build a hierarchy where a dynamic EClass inherits from two or more
> static EClasses, the generated code won't compile.
These combinations don't make a lot of sense. If you don't want a
generated class, it's pretty much impossible to have downstream things
be generated because there's no basis against which to generate. Also,
if you want to extend to base classes that are both generated, you need
a class that an instance of both generated interfaces and you'd need to
generate such a thing because no existing class has that capacity.
--------------070800060407090405020902
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
AJ,<br>
<br>
Comments below.<br>
<br>
<br>
AJ wrote:
<blockquote
cite="mid:5f0612844a79c0e84c0b57f5ed1689de$1@www.eclipse.org"
type="cite">For our new product release, we have to use the 3 flavors
of EMF EClasses.
<br>
</blockquote>
And I though we only had vanilla!<br>
<blockquote
cite="mid:5f0612844a79c0e84c0b57f5ed1689de$1@www.eclipse.org"
type="cite"><br>
The first flavor is a static EClass, which we define in a X.ecore file
and generate using a X.genmodel that has the "dynamic" attribute set to
"false" for the EClass.
<br>
<br>
The second flavor is a dynamic EClass, which we define in a Y.ecore
file and generate using a Y.genmodel that has the "dynamic" attribute
set to "true" for the EClass. This results in no java implementation
class being generated for this EClass. Instead the values of the
class's attributes will be stored in an array.
<br>
</blockquote>
I wonder why you do this?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 03:23:03 GMT 2024
Powered by FUDForum. Page generated in 0.01833 seconds |
] 
Search
Help
Register
Login
Home
