When working with ecore models, we often encounter super/subtype relations on both the container and the member side. We want to easily access both the generic and the specific container members. Intuitively, we used different approaches to fulfill this requirement. This article explores some implementation possibilities and examines their advantages, drawbacks and performance implications.

Scenario

As example, we’ll use an AbstractLibrary containing many AbstractEntrys. We have a specialized BookLibrary containing Books and a specialized MovieLibrary containing Movies and its subtypes SciFis and Comedys. Both AbstractLibrary and AbstractEntry are considered generic, while all other types are considered specific.

Situation

Typical tasks when working with models include verification and generation. We might want to assure every library has at least some content, or generate an XML descriptor for any entry in any library. In both cases, we’re not interested in the specific type of library or entry. At the same time, we might want to check all books to have an author, or generate different descriptors for science fiction movies and comedies.

Therefore, we would need a list of generic entries in any library, and specific typed lists it specific libraries. Unfortunately, ecore prohibits overriding attributes. This limitation is not that important for single references, as we can easily define getter/setter to cast the return/parameter type as required. It gets much more complicated on multi-valued references.

Requirements

On multi-valued references (aka lists), we want to

• get the members of the list,
• add single values, and
• addAll multiple values at once.

for both

• generic and
• specific

types, including type-safety checks at compile-time. We also want to avoid type casts in the code using our model.

Implementation approaches

Luckily, another trait of ecore makes up for the lack of reference overriding: All member access happens through getter/setter methods (as required for JavaBeans). We can leverage this trait to implement an API that feels almost like overriding generic reference types. The basic idea: We replace the missing generic or specific getter by an operation, exposing the same signature as we’d get by the emulated reference. There are two ways to go: Adding generic accessor methods (i. e. holding typed references in the specific containers) or using a generic reference (i. e. adding specific accessor methods to the specific containers).

Generic Accessor Methods

Model

BookLibrary holds a 0..* reference to Book (MovieLibrary accordingly). We want to have an additional method getEntries() for accessing generic entries, so we add this method to AbstractLibrary. In order to avoid superfluous type casts, we need to use a generic type wildcard with upper bound as return type. Entering such a type in the ecore tree editor is quite tricky:

1. Open the ecore file.
2. Make sure menu entry Sample Ecore Editor | Show Generics is checked.
3. If the generic method does not exist yet, create it by right-clicking on the EClass, selecting New Child | EOperation.
4. Open the Properties View for the generic method.
5. Make sure the generic method has an appropriate Name (“getEntries” in our case).
6. If the generic method already has a return type (EType in Properties View), remove it by selecting the empty first row in the drop-down list. Otherwise the context menu entry in the next step will be greyed out. Check also the lowerBound to be 0 and the upperBound to be 1.
7. Right-click on the generic method in the editor tree, select New Child | EGeneric Return Type.
8. In the Properties View of our newly added EGeneric Return Type, select EEList<E> for EClassifier.
9. The EGeneric Return Type in the editor tree now has a new child. Right-click this child, select Add Child | EGeneric Upper Bound Type.
10. The formerly unspecified generic type in the tree editor changes from <?> to <? extends ?>. In the Properties View of the newly added EGeneric Upper Bound Type, set EClassifier to the generic type (AbstractEntry in our case).

Finally, we should arrive at the following picture:

Implementation

We’ll implement the method in both BookLibraryImpl and MovieLibraryImpl rather than AbstractLibraryImpl. The code snippets below contain lots of code created by EcoreGen, we add only our implementation of getEntries():

Generic Attributes

Model

AbstractLibrary holds a 0..* reference to AbstractEntry. We add a method getBooks() with return EType Book, Lower Bound 0 and Upper Bound -1 to BookLibrary (MovieLibrary accordingly). We don’t need any generics in this case.

Implementation

The original implementation approach (dubbed genericAttributes) included a serious amount of dynamic casting. This proved to be problematic, especially performance-wise. A second implementation (genericUnitypeAttributes) performed better.

Generic Attributes

We wrap the generic entries into an UnmodifiableEList in order to keep the interface contract of java.lang.List (add() must fail if nothing was added). The second method included below, getEntries(), is a copy of the code generated into AbstractLibraryImpl, with the type (marked in line 19) set to our specific type. This prevents adding illegal types to the collection.

Generic Unitype^[1] Attributes

Performance tests on the different implementations showed the dynamic casting used in the Generic Attributes implementation to be very expensive. It was introduced to satisfy generics casting limitations of Java. However, we can avoid these casts by exploiting the limitations of Java’s generics implementation (and some @SuppressWarnings annotations already used by EcoreGen). The magic happens by removing all generic types from the manually implemented methods^[2]. The getEntries() implementation is the same as for Generic Attributes, except the removed generic type information on the return type and the @SuppressWarnings annotation. The specific getter implementation is as simple as humanly possible.

Evaluation

Evaluation of the different implementation approaches focuses on three aspects:

• Contract conformance: We want to keep the contracts intact, i. e. adding Movies into a BookLibrary should be prohibited.
• Type safety: As one major reason for the whole endeavor is improving development productivity, we want to keep the type checks of the compiler as good as possible.
• Performance: Increased development productivity should not lead to worse run-time performance.

Contract conformance and type safety

The following table summarizes the evaluation of contract conformance and type safety. We evaluate generic and specific access for each implementation approach. In each case, we check getter, adding one valid/invalid type and multiple valid/invalid types.

Valid denotes types that should be usable in the context (i. e. Book for BookLibrary; Movie, SciFi and Comedy for MovieLibrary), while invalid stands for incompatible types (i. e. Book for MovieLibrary; Movie and subtypes for BookLibrary).

Contract conformance is displayed by the leading symbol: ✓ shows the contract to be fulfilled, ✕ failed to fulfill the contract; ○ are edge cases. The evaluation is done based on the context: For adding an invalid type, the contract is fulfilled (marked with ✓) if the operation fails.

Type safety is shown as second part of each cell:

• for get(), the return type is coded with G for generic type and S for specific type.
• for add(), we note down the type of error reporting.

[A]: The compiler flags any parameter type as invalid generic type; This case needs more research. This article will be updated.

[B]: java.util.Collection.add() is optional, therefore throwing an UnsupportedOperationException fulfills the contract. However, the ecore user would expect the operation call to succeed, thus we evaluated this as edge case.

Adding invalid types to specific type collections (e. g. bookLibrary.getBooks().add(new Movie());) was correctly flagged as a compiler error in all cases. For both Generic Attributes implementations, adding invalid types to generic type collections (e. g. bookLibrary.getEntries().add(new Movie());) was correctly flagged as Exception (there is no way to detect this at compile-time).

Performance

We evaluate the same categories as for contract conformance and type safety (generic and specific access for each implementation approach). Evaluation is done by counting the number of elements in the collection.^[3]

• statistics denotes a plain call to getEntries().size() (for generic) and accordingly getBooks().size().
• instanceof uses the “inverted” getter and checks for the required type in instanceof cascades in a very safe, but slow way.
• dispatch uses Xtend to dispatch on a higher level than instanceof.

+ shows very good performance below measurement precision. − is set for considerably worse performance, which may still be acceptable. −− denotes very poor performance, only usable in a limited set of use cases.

Conclusion

Generic Unitype Attributes provided the best results for all of contract conformance, type safety, and performance. Additionally, the straightforward implementation can easily be reused.

As any emulation, this one has its drawbacks. The most obvious one are the “non-standard” access techniques for member collections, which might confuse some ecore based tools. For both Generic Attribute implementations this effect is manageable, as the “magic” happens on Java level. However, the Generic Accessor Method implementation uses advanced ecore generics functionality and needs to adjust the upperBound of a collection reference to 1, effectively “disguising” the reference’s collection nature.

Resources

All code used for this article is available for download. Some remarks:

• The code was tested under MacOS X 1.7, Eclipse 4.2RC1
• The code contains compile errors (see [A]), but all tests should run successfully.

Acknowledgment

I would like to thank my colleague Christian Dietrich for intensive discussion and help on this post.

Footnotes

[1]: The name has been chosen from the original idea to limit this implementation to one type (“uni type”). As it turned out, this limitation doesn’t apply.

[2]: The compiler removes generic type information anyways, so we don’t introduce an error.

[3]: Evaluating add()-performance requires future research.