Eclipse Community Forums: EMF » Ecore: Type parameter for interface implementation?

Home » Modeling » EMF » Ecore: Type parameter for interface implementation?

Ecore: Type parameter for interface implementation? [message #1787631]

Wed, 30 May 2018 06:14

Eclipse User

Dear all,

What I try to accomplish in the first place, is having an Ecore model where its instances are able to link to classes that all implement the same interface.

As it does not seem to be possible to use the feature "Operation" for that (so that every instance of an Eclass has its own implementation and can be serialized), I tried to have these methods in classes and than have an Eclass in the Ecore which points to a respective Java class.

What I managed to do using the "ETypeParameter" function is to generate something like this:

public interface ESem<ISem> extends EObject {

ISem is the interface all Sem Java classes do implement. But of course, I cannot put a class SemA which implements ISem not into ESem, because the type of SemA is not <ISem> but <SemA extends ISem>.

So, is there a way to model the Ecore model respectively so that the following code is generated

public interface ESem<T extends ISem> extends EObject {

Re: Ecore: Type parameter for interface implementation? [message #1787632 is a reply to message #1787631]

Wed, 30 May 2018 06:40

Eclipse User

Hi

The GenModel Root extends/implements Class/Interface options seem to do what you are looking for. Can you explain why they don't work for you?

And, can you explain your problem much more clearly. I'm not clear what you mean by the feature "Operation" or why it might help solve your problem.

Regards

Ed Willink

Re: Ecore: Type parameter for interface implementation? [message #1787635 is a reply to message #1787632]

Wed, 30 May 2018 07:20

Eclipse User

Thanks for your quick reply,
Ed Willink wrote on Wed, 30 May 2018 06:40

Hi

The GenModel Root extends/implements Class/Interface options seem to do what you are looking for. Can you explain why they don't work for you?

Ed Willink wrote on Wed, 30 May 2018 06:40

And, can you explain your problem much more clearly. I'm not clear what you mean by the feature "Operation" or why it might help solve your problem.

With "operation" I mean the function of adding an operation (i.e. method) to an Eclass. This apparently cannot solve my problem because one Eclass can only have one implementation which then also is not part of the model instantiation.

Basically, I want to combinate to things:
1. some kind of domain model (as Ecore) that manages knowledge and processes how to manipulate a number of given data sources and under which circumstances.
2. a number of Java classes which implement behaviour that is needed for (parts of) the data manipulation code from 1.

In the example, the classes mentioned in 2. all implement the interface ISem.

So my idea is to have an Eclass which points to a Java class. This should generally be possible adding an attribute with the predefined datatype "EJavaClass".
So I added a Eclass "ESem" to the model including an attribute "mySem: EJavaClass".

But this lets Eclipse generate code with a generic property "Class", which lets it point to virtually any valid Java class.

I want to restrict this so that only classes can be used that implement the interface ISem.

I thought that defining a type parameter (i.e., shown as the light gray dashed box attached to an Eclass in the Ecore diagram editor) would be the way to go, but that leads to generated code defining

ESem<ISem>

This doesn't help because a class, be it "SemA" which implements ISem does not have the type ISem but matches

 <T extends ISmr>

, right?

So what I want to know: is there a way to get to this variant, and which modifications I need to make to the Ecore?

Regarding the genmodel options you mentioned: this would apply to all classes in the Ecore model, right?

Re: Ecore: Type parameter for interface implementation? [message #1787641 is a reply to message #1787635]

Wed, 30 May 2018 07:32

Eclipse User

Hi

Sorry I'm totally confused. You originally wrote "Ecore model where its instances" suggesting some property for the entire model but now you seem unhappy that a GenModel option applies to the whole model.,

I am far from clear whether we are talking about the same thing wrt "instances".

You seem to have a clear idea what you want but difficulty in explaining it to me.

Perhaps a 'UML' diagram might make everything clear.

Regards

Ed Willink

Re: Ecore: Type parameter for interface implementation? [message #1787644 is a reply to message #1787641]

Wed, 30 May 2018 07:45

Eclipse User

Ed Willink wrote on Wed, 30 May 2018 07:32

Perhaps a 'UML' diagram might make everything clear.

Sure!
Here we go.

I attached an example which hopefully makes clear what I am trying to accomplish.

In this example, I want to manage a catalog of security checks. Every security check may have a number of security controls.
While, in turn, every security control is carried out by executing code, available as Java classes which all implement the "ISem" interface.

Attachment: class diagram.jpg
(Size: 52.29KB, Downloaded 191 times)

[Updated on: Wed, 30 May 2018 07:51] by Moderator

Re: Ecore: Type parameter for interface implementation? [message #1787647 is a reply to message #1787644]

Wed, 30 May 2018 08:15

Eclipse User

Hi

I don't see a particular problem. EMF supports generics, although they can be difficult to get right. I often resort to looking at the Classic OCL models where generic classes are refined by Ecore/UML variants.

If you have a Papyrus UML diagram, you might see whether UML2Ecore (from the UML Model Editor toolbar menu for a Package works out of the box.)

Otherwise it is difficult to guess at what you have done wrong.

Regards

Ed Willink

Re: Ecore: Type parameter for interface implementation? [message #1789969 is a reply to message #1787647]

Fri, 01 June 2018 06:50

Eclipse User

Ed Willink wrote on Wed, 30 May 2018 08:15

Hi

I don't see a particular problem. EMF supports generics, although they can be difficult to get right.

So, the challenge I face here is that the code generated by the Ecore model I showed you has the generic type ISem:

public interface Sem<ISem> extends EObject {

But this doesn't help me because what I have are classes which all are of different types but all implement the same interface ISem. So my question is:
What do I need to change in the Ecore so that a bounded type parameter like this is generated:

public interface Sem<T extends ISem> extends EObject {

?

I meanwhile discovered the "EGeneric Bound Type" which seems to be what I need but until now I did not manage to apply it the right way, though.

Do you have some hint like link to manual/instruction on how to do this?

Re: Ecore: Type parameter for interface implementation? [message #1789983 is a reply to message #1789969]

Fri, 01 June 2018 10:33

Eclipse User

Create a New -> EType Parameter under Sem and name it T, under that create a new EBound Generic Type and in the properties view for that, set the EClassifier to your ISem EClass.

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="example" nsURI="http://example.org" nsPrefix="example">
  <eClassifiers xsi:type="ecore:EClass" name="ISem"/>
  <eClassifiers xsi:type="ecore:EClass" name="Sem">
    <eTypeParameters name="T">
      <eBounds eClassifier="#//ISem"/>
    </eTypeParameters>
  </eClassifiers>
</ecore:EPackage>

Re: Ecore: Type parameter for interface implementation? [message #1790254 is a reply to message #1789983]

Thu, 07 June 2018 10:23

Eclipse User

Thanks for your comments.

By following your suggestion, the code that is generated by the Genmodel gets my class attributes that store Sem<?>... which are instances of Sem's, not the classes itself.

But nevertheless, after that I finally figured out how this can be solved, by using an EJavaclass attribute in the Ecore. I attached the resulting ecore as file.

However, I now face a different challenge: when I try to persist a model referencing a number of "Sem-classes" later on, I get a DanglingHREFException.

This brings me to the question how EJavaclass attributes are meant to be persisted as part of the model.
I think I've come across some discussions years ago on similar topics, namely these:
https://www.eclipse.org/forums/index.php?t=msg&th=490075
https://www.eclipse.org/forums/index.php/t/304086/

To me it seems like the the advice for this situation is to just go with strings to identify the classes in the model and load them manually using a class loader.

Am I right or do I miss something?

Attachment: My.ecore
(Size: 1.53KB, Downloaded 179 times)

Re: Ecore: Type parameter for interface implementation? [message #1790277 is a reply to message #1790254]

Thu, 07 June 2018 14:44

Eclipse User

DanglingHREFException is answered in the FAQ and has nothing to do with using generics: https://wiki.eclipse.org/EMF/FAQ#I_get_a_DanglingHREFException:_e.g..2C_.22org.eclipse.emf.ecore.xmi.DanglingHREFException:_The_object_.27com.example.Foo.402f5dda_.28.29.27_is_not_contained_in_a_resource..22_What_do_I_need_to_do.3F

EJavaClass instances already support serialization, e.g., org.eclipse.emf.ecore.impl.EcoreFactoryImpl.createEJavaClassFromString(EDataType, String) and org.eclipse.emf.ecore.impl.EcoreFactoryImpl.convertEJavaClassToString(EDataType, Object) so I'm not sure what problem you're having with that.

Re: Ecore: Type parameter for interface implementation? [message #1790541 is a reply to message #1790277]

Tue, 12 June 2018 11:18

Eclipse User

Ed Merks wrote on Thu, 07 June 2018 14:44

DanglingHREFException is answered in the FAQ and has nothing to do with using generics:

Correct. As I wrote, the original problem is solved now but the DanglingHREFException is a new problem I face when trying to save the model.
Ed Merks wrote on Thu, 07 June 2018 14:44

EJavaClass instances already support serialization,
...
so I'm not sure what problem you're having with that.

The problem apparently is that the classes (in my example, a number of classes with the type <? extends ISem>) I have are not part of the resource.
I understand that this is because they are not part of the Ecore model but only referenced by "mySem" attributes.

If I understand the FAQ you mentioned right, only EObjects can be and need to be added to the resource, but the classes I want to refer to are pure Java classes.

The model code generated for the My.ecore from my last post also generates pure Java class attributes and no EJavaclass:

public class SemImpl extends MinimalEObjectImpl.Container implements Sem {
	/**
	 * The cached value of the '{@link #getMySem() <em>My Sem</em>}' attribute.
	 * <!-- begin-user-doc -->
	 * <!-- end-user-doc -->
	 * @see #getMySem()
	 * @generated
	 * @ordered
	 */
	protected Class<? extends ISem> mySem;
...

So, the questions are:
1) Is it possible to have a Ecore model reference pure Java classes and persist it? What actions need to take place then so that the classes are part of the resource and no DanglingHREFException comes up?
2) If not, what changes need to be made to be made to the Ecore/the classes then?

Re: Ecore: Type parameter for interface implementation? [message #1790544 is a reply to message #1790541]

Tue, 12 June 2018 11:37

Eclipse User

Hi

This problem derives from the deign choice for the ETypedElement.eType property. EMF chose to make it a reference which is nice and simple for the referencer but potentially awkward for the definer ; a synthesized type such as a template specialization must be defined (and contained) elsewhere. Multiple references should naturally share one definition.

For OCL usage of Ecore, this necessitates some kind of extra package that contains all the extra types and some smarts to unify multiple copies across multiple files.

(An alternative design choice is taken by UML where a pair of xxx/ownedXxx properties are provided to accommodate a reference when the target exists or local containment where a synthesized target needs containment. The double property is awkward to consume and there may be multiple equivalent definitions.)

You probably need to ensure that the EGenericType for each synthesized Java type is placed in a suitable extra EPackage. For OCL, I call it the Orphanage since it provides a parent for parent-less objects.

Regards

Ed Willink

Re: Ecore: Type parameter for interface implementation? [message #1790576 is a reply to message #1790544]

Wed, 13 June 2018 04:17

Eclipse User

1) You should keep in mind that a java.lang.Class value does not know what type arguments are applied to it; it only knows that type arguments can be specified statically at compile time to correspond to the type parameters. Even at runtime, if you have a List<String> value = new ArrayList<String>(), and you call value.getClass() there is no information at runtime to know that it's a List of String. So a Class value is not sufficient information. In Ecore you'll see that an EClassifier has an instanceTypeName feature (which is just a String) and that captures the full syntax of a type and its arguments. You'd need something like this. In any case, this seems completely unrelated to dangling reference exceptions.
2) EClassifier.instanceTypeName seems similar to what you're trying to do. But I think you're a bit misguided in assuming a java.lang.Class value is sufficient for your purposes. You'd need something more like a java.reflect.ParameterizedType to represent all the information, and you'd of course need to be able to serialize/deserialize such a thing to/from a String representation.

Re: Ecore: Type parameter for interface implementation? [message #1794661 is a reply to message #1790576]

Tue, 04 September 2018 11:55

Eclipse User

Thank you for your replies. I'm not sure if I understood every detail correctly, but I got more convinced that trying to solve my problem fully and directly with EMF may have been an impractical wish in the first place.
Finally, I solved my problem as follows:
The "Sem" class got a String attribute as identifier.
Then, an arbitrary number of Java classes implements the Sem-interface.
I then added an extension point to my project and the classes make use of this extension point.
Thus, during run time, I can query the registration and get all implementations and identify them via their identifier attribute as defined in the EMF metamodel.

Previous Topic:	[EMF Forms] ViewModel testing
Next Topic:	Ecore - method bodies

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 14:29:08 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter