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.