Karsten Thoms

I’m experiencing a strange problem with the font “Monaco”, which is default on my Mac for Eclipse text editors. The font is really nice, but the problem is really annoying. I cannot remember when it first appeared (already a few weeks ago) and what I have changed. Let’s take a look what the problem is:

Recognize the striked through “o” and “l” in “ecoredemomodeldot.ecore”? Of course it should show “ecoredemo/model/dot.ecore”?

Strange thing is that in other text editors the Monaco font displays normally:

Often I change my workspace settings to use Courier New, but that font is far not that nice for text editing.

When using oAW with Java(Beans) based metamodels the most annoying thing is the lack of support for arrays and generic collections (known as Bug#212134).

In fact oAW does already support generics and arrays at runtime, but the editor is not aware of inner types or handling of arrays. The common workaround is to do a type cast whenever accessing a collection value like this:

«FOREACH ((List[Entity])entities).field AS f»...

I found that it was time to solve this issue. One thing to remember is that the implementations of the metamodel for JavaBeans are totally different for the runtime and the editor. While the runtime uses Java reflection to resolve type information, the UI uses JDT. This is more performant for the UI side, but requires implementing each feature twice, or at least assure that all feature would work for runtime and UI the same.

The main task to solve was dealing with JDTs type signatures. The return types of properties (and all other signatures as well) have a coding defined in class Signature. Signatures of primitives, collections and arrays must be translated to oAW’s representation. For example, the signature [Qjava.util.List<QString;>; must be translated to List[List[String]] (the ‘[‘ denotes an array, so the signature declares an array of lists of strings).

This Screenshot shows the same example now without error markers. Also content assist will detect now arrays as List properties.

When generating code one obvious thing that costs performance is doing the actual IO to write the generated text to disk. IO is a bottleneck and needs to be considered intensively when creating large code generators.

I wondered how fast Xpand is in generating files. So I set up a test project that produces simple Java beans with configurable number of files and bean properties per file. Further I wanted to examine the performance of the JavaBeautifier, so I ran optionally the generator with the common used JavaBeautifier postprocessor, which makes use of Eclipse’s JDT.

The project does not need any metamodel nor read any model and has only very few Xpand and Xtend templates. All influences that could influence the measurement of Xpand’s code generation and output should be reduced to a minimum. This is no real-world scenario, since evaluating the model and calling numerous templates will also make up a significant amount of the overall performance. But I wanted to focus only on output performance.

The test project should produce different number of files (1, 10, 100, 1000, 10000) with different sizes. The file size was determined by the number of Java bean properties (instance variable, getter and setter), which was configured with 1, 10, 100 and 1000 properties. Also the file size depends on whether it is formatted by the JavaBeautifier or not. The formatted code is more compact than the produced text, mainly because of whitespace production.

The following table shows the produced file sizes (in kB) depending on number of properties and formatting.

Now let’s take a look at the actual throughput. The graph lines show throuput of different file sizes. The measured throughput consists of two parts:

1. Creating a string representation of the generated file in memory
2. Writing the string buffer to disk

This diagram reveals that the throughput gets better the larger files are. Small files have a hugher overhead. What also can be seen is that with increasing number of iterations performance increases, but at some point it decreases slightly. I assume it has to do with increasing garbage collection, without being able to confirm this yet. Maybe I examine this later.

I was stunned by the maximum throughput with over 7600 kB/s. Wow! I did not expect that. Looking into the output folder showed my that I really produced hundreds of megs files.

This diagram reveals how cost intensive code formatting is. The measured average file creation time was taken from producing 1000 files of different sizes, once without any formatting, the other time with invoking the JavaBeautifier.

As can be seen from this diagram formatting the Code is very costly, growing exponential with file size, starting with factor 2 at an unrealistic small file size. So it is likely that a markable amount of time is eaten up by code formatting.

I want to examine in the future how the output performance can be improved. Now I have a basis for comparing my changes. And hopefully this information is also of use for you.

You can download the sample project here.

Dilbert Comics spiegeln den Wahnsinn, der tagtäglich in Unternehmen abläuft, wunderbar wieder. Gerade in den technischen Abteilungen findet man Ausdrucke von Dilbert Strips an den Wänden hängen. Die Ausdrucke zeigen dann Situationen, mit denen man sich in der Abteilung oder im Projekt identifizieren kann.

Die Menge an Dilberts gibt einen ziemlich direkten Eindruck darin, wie ein Projekt so gerade tickt. Sie ist quasi ein Index für das Geschäftsklima. In jedem vernünftigen Projekt hängen vereinzelte Dilberts. Das zeigt ein gesundes Maß an Humor, mit denen die Projektbeteiligten den Projektalltag begegnen. Viel interessanter ist jedoch, wenn in einer Abteilung übermäßig viele Dilberts an den Wänden hängen. Das ist ein todsicheres Indiz dafür, dass hier etwas ziemlich im Argen liegt. Vor allem wird die Inkompetenz des Managements angeprangert, wahrscheinlich zu Recht. Auf der anderen Seite gibt es auch Abteilungen, in denen man keine Dilberts aushängt. Das zeigt nicht, dass hier alles reibungslos läuft. Eher, dass man hier einen recht langweiligen, humorlosen Arbeitsstil pflegt.

I sometimes face the problem that I copy resources within Eclipse which are attached with subversion information in .svn directories. Eclipse Subversive copies those directories, too, although I often don’t want this. Unfortunately I cannot delete the .svn entries then within Eclipse – Eclipse refuses to delete those entries. Then I must delete the .svn directories from command line on Mac. A further problem is that Subversive creates .svn directories (at least in older versions of this plugin) that are readonly for the current user and removing directories needs a sudo.

This is the command I use for deleting the .svn directories:

sudo find . -name ".svn" -exec rm -rf {} \;

The server hosting the Fornax Platform had a harddisk failure today. Several Fornax services, including the website itself, the Confluence Wiki system, JIRA and the Maven repository are affected. Especially the failure of the Maven repository is critical, many users cannot access it and therefore cannot use Fornax projects at the moment. My colleague Johannes Tysiak is working on reparing the server ASAP and will hopefully fix it this week. Its a shame, since I’m currently working on finally releasing the Fornax infrastructure projects (parent, oAW 4.3 plugin etc.).

Yesterday I attended the International Developer Conference from InterComponentWare (ICW) AG. Karsten Klein, software architect at ICW and developer of the Hybridlabs Beautifier, a Java source formatter component for oAW based on Jalopy, invited me some weeks ago. They have developed a code generator with openArchitectureWare since 2,5 years that is used widely from their customers. This generator makes use of oAW Classic, which will be deprecated for oAW 5. So it was time to come together and talk about migration strategies.

ICW is developing an eHealthCare framework, the ICW eHealth Framework (eHF). Basically the architecture follows the Domain Driven Design principle, enriched by a service oriented architecture. The whole application framework can be generated using the eHF generator. The domain models are produced with MagicDraw 11.5. Some technologies they are using are Spring 2.0, Hibernate with annotations, Maven 1, Axis.

I came to the conference a little bit too late. The motorway A6 was closed due to a heavy accident with 3 trucks. I was in a hotel in Sinsheim, only one motorway exit away. The 20 kilometers took me about 1,5 hours. When I finally arrived I saw the last part of the keynote from Matthias Laux.

The next session was from Karsten Klein and Andreas Kaltenbach about the eHF generator. Since the generator is already in use and in continuous development they did not explained why we need MDSD or a generator, but rather how to model and what changed since their version 2.2. Very interesting was the part about gossip and myths about the generator, where they took the feedback from their users and explained why the drawbacks the users feel are to some extend not real problems.

Another interesting point is that they need to provide templates in different versions to their users, since they cannot require all users to automatically migrate to newer template versions when delivering a new eHF version. This is somehow product line engineering for generators, but they did not use the new oAW PLE features. They just migrated to oAW 4.2.0. They call their workaround “version templates”. The users can decide which template in which version they want to use and migrate softly. The problem they have is that users migrate only when they need a newer template feature. Partly the users have modules generated with different template versions.

After the session I talked to some users that attended the session. There I also heard that they were a bit skeptical about the generator. One developer said that the architecture does not fit for small cases. But it was more a matter of the architecture than the generator that produces code that fits to the architecture.

In the afternoon I attended a very interesting session about application security. The speakers presented the top 10 vulnabilities according to a study 2007 and how they are addressed by the eHF framework. This session really changed my mind regarding application security a bit.

At the end of the conference Karsten Klein, Andreas Kaltenbach, Jochen Köhler and me took a quite place and talked a bit about their generator and possible migrations. I already told them that oAW Classic will be deprecated and not be developed further for oAW 5. Maybe there will be a migration, but no real further development. So they think about possible migration paths for their generator. They use a rather small profile, mainly oriented to the Domain Driven Design paradigm. But they have produced quite a lot template code, about half a meg of Xpand code.

Our idea is to leave the templates in the first step as they are, based upon oAW Classic metamodel. But instantiation won’t be with oAW Classic instantiators, but with the UML 2 adapter and using a model transformation. In the second step a dedicated EMF metamodel will be developed and templates refactored to that. Instantation of that metamodel will be also by an Xtend M2M transformation.

For me it was a very intersting day. Hopefully we come together soon and could help them being further and even more successful and efficient with openArchitectureWare.

The Sculptor team has announced the release of Sculptor 1.3. Sculptor is a code generation platform following the concept of Domain Driven Design. It is based on openArchitectureWare, Spring, Spring Web Flow, Hibernate and Maven technology and is hosted on the Fornax Platform. Using a textual DSL Sculptor generates the whole application frame for a multi-layer application using the mentioned technologies.

Sculptor 1.3 comes with a totally new GUI metamodel for the definition of CRUD GUIs.

The release notes and a migration guide can be found here.

Blogged with Flock

Tags: oAWopenArchitectureWare Fornax Sculptor “Domain Driven Design” Hibernate Spring Maven

The openArchitectureWare team has released the openArchitectureWare 4.3 beta version. This version contains some bugfixes and significant improvements of the Xtext framework.

Note that the Xtext framework changes are not documented sufficient yet and many API changes are within, therefore it cannot be told “production ready” yet. However, Xtext is rather stable now. If you are beginning with Xtext it might be that you do not find all necessary information in the docs yet. If you are already an Xtext user you will miss a migration guide yet. The docs and migration guide will be worked on for the upcoming 5.0 release.

For all users not using Xtext so far the new release brings mainly bug fixes.

Go here for download openArchitectureWare 4.3 beta.

Achim Demelt from eXXcelent Solutions joins the openArchitectureWare team. Achim is an experienced software architect and uses oAW for some years now. During his work he already helped us on testing and bug fixing. Now he is working on a concept for incremental code generation. This work is based on a diploma thesis done by Martina Rapp, who worked formerly at itemis.

We warmly welcome Achim to our team!