DemoCamp Mars in Stuttgart: Great People, Talks, and Food

SpeakersWe had a nice DemoCamp in Stuttgart for Eclipse Mars Release train. About 50 people had a great time alongside great food.

The full agenda, including links to all slides, can be found in the Eclipse Wiki.

MatthiasThe first talk by Matthias Zimmermann showed the Business Application Framework Scout, especially the new features of Mars and the upcoming next release.

MartinAfterwards, Martin Schreiber presented their experience with Tycho and some practical solutions.

JinyingJinying Yu gave an overview of the CloudScale project. It analyzes, estimates and simulates the scalability of a software system, especially for moving it to a cloud service.

MarcoAfter some refreshments and discussions during the break, Marco Eilers impressed with an Xtend interpreter, including tracing between the input model of a transformation and the resulting model or text – in both directions!

MiroThe next talk by Miro Spönemann showed the current state of Xtext on the Web and in IntelliJ. As Miro is the lead developer of the Web variant, he could easily answer all questions in-depth.

HaraldFinally, Harald Mackamul gave an overview of the APP4MC project. They extend the findings of Amalthea project to multi- and many-core systems.

We finished the DemoCamp with more discussions, food, and beer.

I’d like to thank all the great speakers and the attendees for making this DemoCamp fun as ever.

Eclipse DemoCamp 2015 “Mars” at University Stuttgart Vaihingen on July 1st, 17:45 hrs

Right on the heels of this year’s Eclipse “Mars” release, we will again run a DemoCamp in Stuttgart. It will take place

on

Wednesday, July 1st, 2015
17:45 hrs

at

Stuttgart University in Stuttgart-Vaihingen
Informatik Building
Universitätsstraße 38
70569 Stuttgart
Room Hörsaal 38.03

Details around the DemoCamp can be found at
https://wiki.eclipse.org/Eclipse_DemoCamps_Mars_2015/Stuttgart

As usual, admission is free, but please register at the above URL to help us plan the event.

Demos will include

  • Eclipse Scout: What’s new with Mars
  • Maven Tycho in practice
  • Interpreting Xtend: How to do it and why
  • Xtext for other platforms – Integration in IntelliJ IDEA and web applications
  • CloudScale Method for Analysing Scalability, Elasticity and Effieciency Engineering
  • APP4MC – a new Eclipse project proposal

Meet the IoT, Dependency Management, the local Eclipse Community and more at the DemoCamp Luna in Stuttgart!

DemoCampStuttgartSmall
On July 2nd, the Eclipse DemoCamp for the Luna release train will take place at the Stuttgart University, Vaihingen campus. You will see demos on several Internet-of-Things projects, including HTML5 device UIs build with Franca, using MQTT and Paho to connect Webpages, and an extensible C for developing embedded software. In addition, there will be demos on modern software translation with Jabylon, Eclipse usability, and package dependency diagnosis. There will be plenty of time, food and drinks to get in touch with speakers and members of the local Eclipse Community in general.

Detailed information can be found at: https://wiki.eclipse.org/Eclipse_DemoCamps_Luna_2014/Stuttgart

Eclipse Demo Camp Kepler Stuttgart Retrospective

Welcome!

Welcome!

We had a great DemoCamp in Stuttgart. About sixty people crowded the room and welcomed every beverage the hotel could come up with.

The room just sufficed

The room just sufficed

Please refer to the Eclipse Wiki for abstracts, slides and additional links for all demos.

Andreas Sewe shows Hippie Code Completion

Andreas Sewe shows Hippie Code Completion

Andreas Sewe demonstrated Code Recommenders, including their newest feature called Hippie Code Completion. He explained the various ways Eclipse supports the developer with code proposals. After a quick recap of already available Code Recommenders features we saw how Hippie Code Completion collects code patterns live during input and distills proposals on the spot.

Jan Stamer on Eclipse Gemini

Jan Stamer on Eclipse Gemini

Jan Stamer gave an overview of Eclipse Gemini, the Eclipse implementation of OSGi Enterprise specification. He compared OSGi Enterprise to Java EE and showed implementation examples for database access, JPA, and dependency injection.

Dominik Obermaier connects anything via Eclipse Paho

Dominik Obermaier connects anything via Eclipse Paho

Dominik Obermaier swapped his slot with the Contracts for Java talk. He demonstrated Eclipse Paho, the umbrella project for machine-to-machine (M2M) protocols. He argued for MQTT as lightweight, low-bandwith, and fault-tolerant protocol suited for small systems. He implemented live a publisher and subscriber of MQTT messages within a few lines of code.

Sebastian Zarnekow in passion about Xtend

Sebastian Zarnekow in passion about Xtend

Sebastian Zarnekow demonstrated Xtend, aka Java on steroids. He began by writing a simple list processing example in Java style. Step by step, he refactored the code using Xtend features, thus becoming far more concise and readable. Finally, he gave a crash course on one of Xtend’s newest features, Active Annotations: Sebastian live developed an Annotation to enable logging on any class.

I had been warned that once we opened the windows, the air conditioning would shut down. After stepping outside and back into the room, I decided in favor of at least some oxygen, taking the risk on the air conditioning. Unfortunately, the warning came true, and we had an increasingly hot second term.

Andreas Graf shows a dozen Eclipse projects combined to allow Function Oriented Development

Andreas Graf shows a dozen Eclipse projects combined to allow Function Oriented Development

Andreas Graf demonstrated the current state of an automotive research project. As an example, he picked the seemingly simple car function of start-stop system to save fuel at a traffic light. He explaind how this function concerns lots of different car subsystems. Most likely, they are provided by different external suppliers and managed by different internal departments. The research project IMES combines lots of Open Source and some commercial Eclipse based projects to tackle this complexity. Andreas showed this combination to enable advanced concepts like traceability, feature and variant modelling, and impact analysis.

Hagen Buchwald explains Stefan Schürle's demonstration of Contracts for Java

Hagen Buchwald explains Stefan Schürle’s demonstration of Contracts for Java

Stefan Schürle stood in for Florian Meyerer to demonstrate Contracts for Java together with Hagen Buchwald. Hagen started by explaining the basic ideas of contracts. Every step Hagen explained, Stefan implemented within the C4J framework. The demo application provided a student’s bank account, guarded by contracts to disallow debit.

Timo Kehrer explains SiLift

Timo Kehrer explains SiLift

Timo Kehrer explained SiLift, the Eclipse implementation of his concept how to compare/merge models on a meaningful level. He focused on edit operations as basic blocks rather than model modifications. Timo illustrated how SiLift can detect the changes of some edit operations automatically; more complex examples need to be described by the developer. He spent quite some time on putting the concept into usable tools.

Sorry Ed, I forgot to take a picture (-:

Sorry Ed, I forgot to take a picture (-:

Ed Merks concluded the sessions with his “first non-modelling talk in the last ten years”, as he put it. He told about his experience on improving Java performance in two customer projects. He learned not to trust anything and to be paranoid about common knowledge, each and any measurement, experts, and even oneself. He showed how to establish some baseline by looking for the quickest action one environment can measure (limited by timer resolution) and the fastest operations a JVM is capable. On this baseline, he wrote a simple framework to work on more complex cases. The extended slides offer much more detail than Ed was able to squeeze into the 20 minute slot.

After more than three hours of new and exciting ideas, combined with a jungle-like climate in the room, both the speakers and the audience rushed for the buffet and more cool drinks. We had a relaxed evening with lots of interesting discussions, leaving the premises just about midnight.

My special thanks go to all the speakers, arriving from all over Germany on their own expenses to show us their Cool Stuff™.

I appreciate all our guests participating in the DemoCamp and the survey we sent. We got more than 50 per cent response rate — thank you! The survey resulted in a favor for short slots in English. The demo vs. presentation question came out more closely, with advantage for a mixed program.

Eclipse DemoCamp Kepler in Stuttgart on 2013-07-17 17:00

At Wednesday, July 17th, itemis sponsors this year’s Eclipse DemoCamp in Stuttgart. All details can be found at the Eclipse Wiki. We’ll start at 5 pm at the Ibis Styles Hotel in Bad Cannstatt.

We could compile an agenda from a wide variety of topics, reaching from cloud-supported code recommendations and enterprise OSGi adaption through programming language improvements using contracts and more concise syntax, function oriented development and machine-to-machine communication to model comparison and Java performance tuning tips. The Eclipse Wiki contains summaries for each demo.

There will be plenty of time to talk to the presenters and other attendees. itemis provides snacks and beverages so we can have an interesting and pleasant evening.

I’m looking forward to meet you in three weeks! Please register so we can spread last-minute updates as necessary.

Merge Text Files with Ant

Apache Ant has lots of useful built-in tasks. However, a task for merging text files is not among them. Fortunately, we can combine some built-in tasks to achieve this goal.

Below, you’ll find the macro along a simple demo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<project default="merge-demo">

<target name="merge-demo">
    <merge tofile="merged.txt">
        <sourcefiles>
            <fileset dir="inputfiles"></fileset>
        </sourcefiles>
    </merge>
</target>

    <!-- = = = = = = = = = = = = = = = = =
     macrodef: merge          
    = = = = = = = = = = = = = = = = = -->
    <macrodef name="merge">
        <attribute name="tofile"></attribute>
        <element name="sourcefiles"></element>
       
        <sequential>
            <tempfile property="temp.file" prefix="ant.merge." deleteonexit="true"></tempfile>
           
            <concat destfile="${temp.file}" fixlastline="true">
                <sourcefiles></sourcefiles>
            </concat>
           
            <copy file="${temp.file}" tofile="@{tofile}">
                <filterchain>
                    <tokenfilter>
                        <linetokenizer></linetokenizer>
                    </tokenfilter>
                    <sortfilter></sortfilter>
                    <uniqfilter></uniqfilter>
                </filterchain>
            </copy>
        </sequential>
    </macrodef>
</project>

Remarks and Caveats

  • Contents of all files are sorted by line.
  • Duplicate lines are removed.

Example

The example runs on the following directory:
ant-merge-dirstructure

with the following file contents:

file1.txt

# random prefix	file	line	remark
7609	file1.txt	1
24307	file1.txt	2
31889	file1.txt	3	no newline afterwards

file2.txt

# random prefix	file	line	remark
5808	file2.txt	1
32706	file2.txt	2	preceding empty line

7848	file2.txt	3	following empty line
17727	file2.txt	4
3071	file2.txt	5	one newline afterwards

file3.txt

# random prefix	file	line	remark
16411	file3.txt	1
10605	file3.txt	2	followed by several newlines



Once we run the Ant script, the resulting file will look as follows:
merged.txt


# random prefix	file	line	remark
10605	file3.txt	2	followed by several newlines
16411	file3.txt	1
17727	file2.txt	4
24307	file1.txt	2
3071	file2.txt	5	one newline afterwards
31889	file1.txt	3	no newline afterwards
32706	file2.txt	2	preceding empty line
5808	file2.txt	1
7609	file1.txt	1
7848	file2.txt	3	following empty line

Eclipse Juno DemoCamp Stuttgart 2012

itemis sponsored the Eclipse DemoCamp Stuttgart yesterday. About 60 participants saw impressive demonstrations:

  • Frank Gerhardt started with a demonstration of GEF running in a browser on both PCs and mobile devices. He emphasized the few changes required to GEF code for using it in the browser. Once loaded, all features known from GEF (shape modification, undo/redo, grid, snap to objects, …) run entirely without server interaction. The interaction is adjusted to mobile devices: Click areas are enlarged, and the area below your fingertip is shown in a separate “magnifiying glass” to enable precise modifications.
  • Jochen Krause showed a somewhat opposite approach to mobile apps. RAP mobile provides a unified development environment (including all Eclipse tools magic, debugging and live deployment) for different target platforms. The applications are compiled to native code for each platform. Data processing is server based, with both its advantages and drawbacks: You don’t need to worry about lost data on stolen devices, but you need constant connectivity.
  • Oliver Böhm provided an overview on ten years of PatternTesting. PatternTesting aims at assuring architectural decisions by using aspect-oriented code instrumentation.
  • Mark Brörkens introduced RMF, the Eclipse implementation of OMG ReqIF (Requirements Interchange Format). RMF will become the solid foundation of requirement modeling tools in the Eclipse ecosphere, much the same way Eclipse UML became the de-facto standard implementation.
  • Axel Terfloth demonstrated the remarkable state machine modeling YAKINDU Statechart Tools. They mix the best of graphical and textual modeling and include simulation and debugging capabilities. Additionally, it can attach to domain specific models, shown with a Flash application.
  • Ed Merks solemnized the grand finale with Xcore, an textual syntax for describing ecore models. It supports all ecore features, and then some: Operation implementations inside the model (without quirky annotations), documentation inside ecore models (like Javadoc), live metamodel update inside the reflective editor, and refactoring support down to user-written code.

Before, during and after the demos we had interesting discussions, lots of food and chilled beer.

Parallel Type Trees: Generic Attribute vs. Generic Accessor Method

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():

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class genericAccessorMethods.BookLibraryImpl extends AbstractLibraryImpl implements BookLibrary {
    @Override
    public EList<? extends AbstractEntry> getEntries() {
        return getBooks();
    }

    // ...

    /**
     * The cached value of the '{@link #getBooks() <em>Books</em>}' containment reference list.
     * <!-- begin-user-doc --> <!-- end-user-doc -->
     * @see #getBooks()
     * @generated
     * @ordered
     */

    protected EList<Book> books;

    // ...

    /**
     * <!-- begin-user-doc --> <!-- end-user-doc -->
     * @generated
     */

    public EList<Book> getBooks() {
        if (books == null) {
            books = new EObjectContainmentEList<Book>(Book.class, this, GenericAccessorMethodsPackage.BOOK_LIBRARY__BOOKS);
        }
        return books;
    }
} // BookLibraryImpl
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class genericAccessorMethods.MovieLibraryImpl extends AbstractLibraryImpl implements MovieLibrary {
    @Override
    public EList<? extends AbstractEntry> getEntries() {
        return getMovies();
    }

    // ...

    /**
     * The cached value of the '{@link #getMovies() <em>Movies</em>}' containment reference list.
     * <!-- begin-user-doc --> <!-- end-user-doc -->
     * @see #getMovies()
     * @generated
     * @ordered
     */

    protected EList<Movie> movies;

    // ...

    /**
     * <!-- begin-user-doc --> <!-- end-user-doc -->
     * @generated
     */

    public EList<Movie> getMovies() {
        if (movies == null) {
            movies = new EObjectContainmentEList<Movie>(Movie.class, this, GenericAccessorMethodsPackage.MOVIE_LIBRARY__MOVIES);
        }
        return movies;
    }
} // MovieLibraryImpl

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class genericAttributes.BookLibraryImpl extends AbstractLibraryImpl implements BookLibrary {
    /**
     * <!-- begin-user-doc --> <!-- end-user-doc -->
     *
     * @generated NOT
     */
    public EList<Book> getBooks() {
        return new UnmodifiableEList<Book>(getEntries().size(), getEntries()
                .toArray());
    }

    /**
     * @generated NOT
     */
    @Override
    public EList<AbstractEntry> getEntries() {
        if (entries == null) {
            entries = new EObjectContainmentEList<AbstractEntry>(
                Book.class,
                this,
                GenericAttributesPackage.ABSTRACT_LIBRARY__ENTRIES
            );
        }
        return entries;
    }
} // BookLibraryImpl
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class genericAttributes.MovieLibraryImpl extends AbstractLibraryImpl implements MovieLibrary {
    /**
     * <!-- begin-user-doc --> <!-- end-user-doc -->
     *
     * @generated NOT
     */
    public EList<Movie> getMovies() {
        return new UnmodifiableEList<Movie>(getEntries().size(), getEntries()
                .toArray());
    }

    /**
     * @generated NOT
     */
    @Override
    public EList<AbstractEntry> getEntries() {
        if (entries == null) {
            entries = new EObjectContainmentEList<AbstractEntry>(
                Movie.class,
                this,
                GenericAttributesPackage.ABSTRACT_LIBRARY__ENTRIES
            );
        }
        return entries;
    }
} // MovieLibraryImpl
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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class genericUnitypeAttributes.BookLibraryImpl extends AbstractLibraryImpl implements BookLibrary {
    /**
     * <!-- begin-user-doc --> <!-- end-user-doc -->
     *
     * @generated NOT
     */

    @SuppressWarnings({ "rawtypes", "unchecked" })
    public EList getBooks() {
        return getEntries();
    }

    /**
     * @generated NOT
     */

    @SuppressWarnings({ "rawtypes", "unchecked" })
    @Override
    public EList getEntries() {
        if (entries == null) {
            entries = new EObjectContainmentEList<AbstractEntry>(
                Book.class,
                this,
                GenericUnitypeAttributesPackage.ABSTRACT_LIBRARY__ENTRIES
            );
        }
        return entries;
    }
} // BookLibraryImpl
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class genericUnitypeAttributes.MovieLibraryImpl extends AbstractLibraryImpl implements MovieLibrary {
    /**
     * <!-- begin-user-doc --> <!-- end-user-doc -->
     *
     * @generated NOT
     */

    @SuppressWarnings({ "rawtypes", "unchecked" })
    public EList getMovies() {
        return getEntries();
    }

    /**
     * @generated NOT
     */

    @SuppressWarnings({ "rawtypes", "unchecked" })
    @Override
    public EList getEntries() {
        if (entries == null) {
            entries = new EObjectContainmentEList<AbstractEntry>(
                Movie.class,
                this,
                GenericUnitypeAttributesPackage.ABSTRACT_LIBRARY__ENTRIES
            );
        }
        return entries;
    }
} // MovieLibraryImpl

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.
genericAccessorMethods genericAttributes genericUnitypeAttributes
generic specific generic specific generic specific
get() ✓ ​[? extends G] [S] [G] [S] [G] [S]
add() [validType] ✕ (compiler)[A] ○ (Unsupported​Operation​Exception[B])
add() [invalidType] ✕ (compiler)[A] ✓ (compiler) ✓ (Array​Store​Exception) ✓ (compiler) ✓ (Array​Store​Exception) ✓ (compiler)
addAll() [validType] ✕ (compiler)[A] ○ (Unsupported​Operation​Exception[B])
addAll() [invalidType] ✕ (compiler)[A] ✓ (compiler) ✓ (Array​Store​Exception) ✓ (compiler) ✓ (Array​Store​Exception) ✓ (compiler)

[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.

genericAccessorMethods genericAttributes genericUnitypeAttributes
generic specific generic specific generic specific
statistics + + + + +
instanceof + −− −− + −−
dispatch + + + +

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.