Bugzilla – Full Text Bug Listing
| Summary: | GenericType resolution for subclass of BaseMap$Entry | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Michael Woski <woskimi> |
| Component: | Core | Assignee: | Ed Merks <Ed.Merks> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | 2.7.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
Sorry, maps aren't designed to work this way. You must fully define the key and feature types in the map entry class. I could investigate whether it's feasible to enhance the design to allow type parameters, but that's a significant bit of design work that will likely require some complex changes. (In reply to comment #1) Hi Ed, certainly I'm a bit naiv, but at least my abstract base class IndexedObject is properly generated, including its type parameter. It's only when I use it in a reference with a concrete type that the generated code does not have that concrete type, but rather the literal of the type parameter of my subclassed IndexedObject. When you wrap an existing Java interface, the number of type parameters must be the same, and the bounds on each type parameter must be the same. This is essentially the same issue as in https://bugs.eclipse.org/bugs/show_bug.cgi?id=384699 |
I'm trying to create an ecore model that needs map references. I therefore created a generic stereotype that has its "class instance name" property set to java.util.Map$Entry. The ecore model roughly translates to this: abstract IndexedObject<T> { Character key T value } I then use it like this: ContainmentClass { IndexedObject<MyWrappedObject> wrappedObjects } When I generate the java code for this model the IndexedObject reference is translated into a Map.Entry, as I would have expected. However, the type parameter of IndexedObject<MyWrappedObject> is not getting resolved properly; instead of getting Map.Entry<Character, MyWrappedObject> a Map.Entry<Character, T> is being generated. My guess is that this only needs some minor tweaking of the model parser, since syntactically everything looks alright. I hope I could make my point clear, thx.