Home » Modeling » EMF » Issues with EMF Generics
|
| Re: Issues with EMF Generics [message #538677 is a reply to message #538623] |
Tue, 08 June 2010 11:56   |
|
Hi, Joachim,
I think you're feeling the effects of "erasure." This is Java's
terminology that indicates how generic types are really just a
compile-time constraint, and are not evident at run-time (they are
"erased.")
Firstly, the non-abstract BORepository type was a problem because its
type parameter had to be substituted by a subtype of BOClass. Your
first definition of BORepository didn't have any such subtypes, but your
second did (the Product- and TariffRepository).
The problem of being able to reference the "wrong" types is explained by
the references in question being "erased" to a signature of type
BOClass. Thus, both ProductRepository and TariffRepository at run-time
only know that they reference some kind of BOClass. This is what you
see in the editor, which works by Ecore reflection and is affected by
generic erasure in the same was a Java reflection is.
The *only* benefit of the generic type signatures is in usage of the
generated API in your business logic. In particular, they cannot
actually express constraints that the EMF run-time will enforce.
HTH,
Christian
On 08/06/10 04:49 AM, Joachim Dulinski wrote:
> Hello all.
>
> trying to model business objects of an application I ran into some
> issues with generics I couldn't figure out the best / supposed way to
> solve.
>
> I couldn't attach the ecore file, so the following description will have
> to do: I want to model common properties of all business objects via a
> root type and for type safety I use generics. One of these properties is
> that an object can have a reference to another one as long as both are
> of the same type, thus I tried for the (abstract) root class
> BOClass<T extends BOClass<T>>
> name: EString
> prototype[0..1]: T (non-containment)
>
> To explain the issues I need two subclasses, let's say
>
> Product -> BOClass<Product>
> Tariff -> BOClass<Tariff>
>
> At the end I want the user to define instances (parametrizing
> calculations) using the generated editor as much as possible and to be
> able to put them in one resource I modeled a container, lets say
>
> BORepository<T extends BOClass<T>>
> content[1..*]: T (containment)
>
> Now the issues (I tried this with Galileo and Helios (both up to date),
> and found the same behavior. The genmodel I am using is unchanged):
>
> 1. From the point of view of its usage in the code I didn't see a
> necessity to make BORepository abstract, but in this case the generated
> model code gives me the error:
>
> Bound mismatch: The generic method createBORepository() of type
> BosFactory is not applicable for the arguments (). The inferred type
> BOClass<BOClass<T>> is not a valid substitute for the bounded parameter
> <T extends BOClass<T>>
>
> 2. If I make BORepository abstract and add two repositories for my classes
> ProductRepository -> BORepository<Product>
> TariffRepository -> BORepository<Tariff>
>
> the error disappears but using the generated editor to define products
> starting with a product repository I was a bit surprised that I could
> add products and tariffs into a product repository. The same is true for
> the prototype reference, i.e. on a product I can add a reference to a
> tariff. And all this is true working with a dynamic instance. How can I
> prevent this? Am I doing something wrong?
>
> Thanks & cheers,
> Joachim
>
|
|
|
| Re: Issues with EMF Generics [message #538787 is a reply to message #538677] |
Tue, 08 June 2010 15:43 |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000609090008060905030407
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Guys,
Yes, the problem is that everything being generated is based on the
erased view of Ecore but there are cases where this erases constraints
as observed in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289859
The bound mismatch issue might be a real bug, but I need a test case to
demonstrate that. Note that even when the Ecore model has errors, you
can still generate the Java model by turning to the main tab in the
Generator. If the generated Java doesn't have the same problem, then
it's probably a bug in Ecore's validation. I need a test case and a
bugzilla if that's the case.
Christian W. Damus wrote:
> Hi, Joachim,
>
> I think you're feeling the effects of "erasure." This is Java's
> terminology that indicates how generic types are really just a
> compile-time constraint, and are not evident at run-time (they are
> "erased.")
>
> Firstly, the non-abstract BORepository type was a problem because its
> type parameter had to be substituted by a subtype of BOClass. Your
> first definition of BORepository didn't have any such subtypes, but
> your second did (the Product- and TariffRepository).
>
> The problem of being able to reference the "wrong" types is explained
> by the references in question being "erased" to a signature of type
> BOClass. Thus, both ProductRepository and TariffRepository at
> run-time only know that they reference some kind of BOClass. This is
> what you see in the editor, which works by Ecore reflection and is
> affected by generic erasure in the same was a Java reflection is.
>
> The *only* benefit of the generic type signatures is in usage of the
> generated API in your business logic. In particular, they cannot
> actually express constraints that the EMF run-time will enforce.
>
> HTH,
>
> Christian
>
> On 08/06/10 04:49 AM, Joachim Dulinski wrote:
>> Hello all.
>>
>> trying to model business objects of an application I ran into some
>> issues with generics I couldn't figure out the best / supposed way to
>> solve.
>>
>> I couldn't attach the ecore file, so the following description will have
>> to do: I want to model common properties of all business objects via a
>> root type and for type safety I use generics. One of these properties is
>> that an object can have a reference to another one as long as both are
>> of the same type, thus I tried for the (abstract) root class
>> BOClass<T extends BOClass<T>>
>> name: EString
>> prototype[0..1]: T (non-containment)
>>
>> To explain the issues I need two subclasses, let's say
>>
>> Product -> BOClass<Product>
>> Tariff -> BOClass<Tariff>
>>
>> At the end I want the user to define instances (parametrizing
>> calculations) using the generated editor as much as possible and to be
>> able to put them in one resource I modeled a container, lets say
>>
>> BORepository<T extends BOClass<T>>
>> content[1..*]: T (containment)
>>
>> Now the issues (I tried this with Galileo and Helios (both up to date),
>> and found the same behavior. The genmodel I am using is unchanged):
>>
>> 1. From the point of view of its usage in the code I didn't see a
>> necessity to make BORepository abstract, but in this case the generated
>> model code gives me the error:
>>
>> Bound mismatch: The generic method createBORepository() of type
>> BosFactory is not applicable for the arguments (). The inferred type
>> BOClass<BOClass<T>> is not a valid substitute for the bounded parameter
>> <T extends BOClass<T>>
>>
>> 2. If I make BORepository abstract and add two repositories for my
>> classes
>> ProductRepository -> BORepository<Product>
>> TariffRepository -> BORepository<Tariff>
>>
>> the error disappears but using the generated editor to define products
>> starting with a product repository I was a bit surprised that I could
>> add products and tariffs into a product repository. The same is true for
>> the prototype reference, i.e. on a product I can add a reference to a
>> tariff. And all this is true working with a dynamic instance. How can I
>> prevent this? Am I doing something wrong?
>>
>> Thanks & cheers,
>> Joachim
>>
>
--------------000609090008060905030407
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guys,<br>
<br>
Yes, the problem is that everything being generated is based on the
erased view of Ecore but there are cases where this erases constraints
as observed in<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=289859">https://bugs.eclipse.org/bugs/show_bug.cgi?id=289859</a><br>
</blockquote>
The bound mismatch issue might be a real bug, but I need a test case to
demonstrate that. Note that even when the Ecore model has errors, you
can still generate the Java model by turning to the main tab in the
Generator. If the generated Java doesn't have the same problem, then
it's probably a bug in Ecore's validation. I need a test case and a
bugzilla if that's the case.<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:hulb4g$m7c$1@build.eclipse.org" type="cite">Hi,
Joachim,
<br>
<br>
I think you're feeling the effects of "erasure." This is Java's
terminology that indicates how generic types are really just a
compile-time constraint, and are not evident at run-time (they are
"erased.")
<br>
<br>
Firstly, the non-abstract BORepository type was a problem because its
type parameter had to be substituted by a subtype of BOClass. Your
first definition of BORepository didn't have any such subtypes, but
your second did (the Product- and TariffRepository).
<br>
<br>
The problem of being able to reference the "wrong" types is explained
by the references in question being "erased" to a signature of type
BOClass. Thus, both ProductRepository and TariffRepository at run-time
only know that they reference some kind of BOClass. This is what you
see in the editor, which works by Ecore reflection and is affected by
generic erasure in the same was a Java reflection is.
<br>
<br>
The *only* benefit of the generic type signatures is in usage of the
generated API in your business logic. In particular, they cannot
actually express constraints that the EMF run-time will enforce.
<br>
<br>
HTH,
<br>
<br>
Christian
<br>
<br>
On 08/06/10 04:49 AM, Joachim Dulinski wrote:
<br>
<blockquote type="cite">Hello all.
<br>
<br>
trying to model business objects of an application I ran into some
<br>
issues with generics I couldn't figure out the best / supposed way to
<br>
solve.
<br>
<br>
I couldn't attach the ecore file, so the following description will
have
<br>
to do: I want to model common properties of all business objects via a
<br>
root type and for type safety I use generics. One of these properties
is
<br>
that an object can have a reference to another one as long as both are
<br>
of the same type, thus I tried for the (abstract) root class
<br>
BOClass<T extends BOClass<T>>
<br>
name: EString
<br>
prototype[0..1]: T (non-containment)
<br>
<br>
To explain the issues I need two subclasses, let's say
<br>
<br>
Product -> BOClass<Product>
<br>
Tariff -> BOClass<Tariff>
<br>
<br>
At the end I want the user to define instances (parametrizing
<br>
calculations) using the generated editor as much as possible and to be
<br>
able to put them in one resource I modeled a container, lets say
<br>
<br>
BORepository<T extends BOClass<T>>
<br>
content[1..*]: T (containment)
<br>
<br>
Now the issues (I tried this with Galileo and Helios (both up to date),
<br>
and found the same behavior. The genmodel I am using is unchanged):
<br>
<br>
1. From the point of view of its usage in the code I didn't see a
<br>
necessity to make BORepository abstract, but in this case the generated
<br>
model code gives me the error:
<br>
<br>
Bound mismatch: The generic method createBORepository() of type
<br>
BosFactory is not applicable for the arguments (). The inferred type
<br>
BOClass<BOClass<T>> is not a valid substitute for the
bounded parameter
<br>
<T extends BOClass<T>>
<br>
<br>
2. If I make BORepository abstract and add two repositories for my
classes
<br>
ProductRepository -> BORepository<Product>
<br>
TariffRepository -> BORepository<Tariff>
<br>
<br>
the error disappears but using the generated editor to define products
<br>
starting with a product repository I was a bit surprised that I could
<br>
add products and tariffs into a product repository. The same is true
for
<br>
the prototype reference, i.e. on a product I can add a reference to a
<br>
tariff. And all this is true working with a dynamic instance. How can I
<br>
prevent this? Am I doing something wrong?
<br>
<br>
Thanks & cheers,
<br>
Joachim
<br>
<br>
</blockquote>
<br>
</blockquote>
</body>
</html>
--------------000609090008060905030407--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Issues with EMF Generics [message #538965 is a reply to message #538787] |
Wed, 09 June 2010 08:36 |
Joachim Dulinski
Messages: 5
Registered: June 2010 |
Junior Member |
|
|
Hello and thanks for your help. So it's type erasure at the play. Somehow I hoped that EMF keeps track of generic types behind the scenes, but of course no offense meant. I'll see whether I can build the types into the superclasses using type tokens.
Concerning the bound mismatch in the generated model code I played a little bit around and found that this bound mismatch occurs only if the bound in the container has a type parameter, that is with the modeled classes (not abstract)
BOClass<T>
BORepository<T extends BOClass<T>>
(without any attributes) the bound mismatch occurs in the generated model code but erasing the type parameter on BOClass
BOClass
BORepository<T extends BOClass>
the generated model code has no errors (the model validates without errors or warnings in both cases).
@Ed: Because of this behavior as suggested I filed a bugzilla (316257) with the Ecore model causing the error. If there are further questions don't hesitate to contact me.
Thanks for your help,
Joachim
[quote title=Ed Merks wrote on Tue, 08 June 2010 11:43]
Guys,
Yes, the problem is that everything being generated is based on the
erased view of Ecore but there are cases where this erases constraints
as observed in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289859
The bound mismatch issue might be a real bug, but I need a test case to
demonstrate that. Note that even when the Ecore model has errors, you
can still generate the Java model by turning to the main tab in the
Generator. If the generated Java doesn't have the same problem, then
it's probably a bug in Ecore's validation. I need a test case and a
bugzilla if that's the case.
Christian W. Damus wrote:
> Hi, Joachim,
>
> I think you're feeling the effects of "erasure." This is Java's
> terminology that indicates how generic types are really just a
> compile-time constraint, and are not evident at run-time (they are
> "erased.")
>
> Firstly, the non-abstract BORepository type was a problem because its
> type parameter had to be substituted by a subtype of BOClass. Your
> first definition of BORepository didn't have any such subtypes, but
> your second did (the Product- and TariffRepository).
>
> The problem of being able to reference the "wrong" types is explained
> by the references in question being "erased" to a signature of type
> BOClass. Thus, both ProductRepository and TariffRepository at
> run-time only know that they reference some kind of BOClass. This is
> what you see in the editor, which works by Ecore reflection and is
> affected by generic erasure in the same was a Java reflection is.
>
> The *only* benefit of the generic type signatures is in usage of the
> generated API in your business logic. In particular, they cannot
> actually express constraints that the EMF run-time will enforce.
>
> HTH,
>
> Christian
>
> On 08/06/10 04:49 AM, Joachim Dulinski wrote:
>> Hello all.
>>
>> trying to model business objects of an application I ran into some
>> issues with generics I couldn't figure out the best / supposed way to
>> solve.
>>
>> I couldn't attach the ecore file, so the following description will have
>> to do: I want to model common properties of all business objects via a
>> root type and for type safety I use generics. One of these properties is
>> that an object can have a reference to another one as long as both are
>> of the same type, thus I tried for the (abstract) root class
>> BOClass<T extends BOClass<T>>
>> name: EString
>> prototype[0..1]: T (non-containment)
>>
>> To explain the issues I need two subclasses, let's say
>>
>> Product -> BOClass<Product>
>> Tariff -> BOClass<Tariff>
>>
>> At the end I want the user to define instances (parametrizing
>> calculations) using the generated editor as much as possible and to be
>> able to put them in one resource I modeled a container, lets say
>>
>> BORepository<T extends BOClass<T>>
>> content[1..*]: T (containment)
>>
>> Now the issues (I tried this with Galileo and Helios (both up to date),
>> and found the same behavior. The genmodel I am using is unchanged):
>>
>> 1. From the point of view of its usage in the code I didn't see a
>> necessity to make BORepository abstract, but in this case the generated
>> model code gives me the error:
>>
>> Bound mismatch: The generic method createBORepository() of type
>> BosFactory is not applicable for the arguments (). The inferred type
>> BOClass<BOClass<T>> is not a valid substitute for the bounded parameter
>> <T extends BOClass<T>>
>>
>> 2. If I make BORepository abstract and add two repositories for my
>> classes
>> ProductRepository -> BORepository<Product>
>> TariffRepository -> BORepository<Tariff>
>>
>> the error disappears but using the generated editor to define products
>> starting with a product repository I was a bit surprised that I could
>> add products and tariffs into a product repository. The same is true for
>> the prototype reference, i.e. on a product I can add a reference to a
>> tariff. And all this is true working with a dynamic instance. How can I
>> prevent this? Am I doing something wrong?
>>
>> Thanks & cheers,
>> Joachim
>>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 22:02:40 GMT 2024
Powered by FUDForum. Page generated in 0.03849 seconds |
] 
Search
Help
Register
Login
Home
