CodeGeneration 2008

I am currently attending the CodeGeneration 2008 conference at Cambridge (UK).

It is very inspiring to meet so many people involved in model-driven software development. Many of them come from the Microsoft DSL tools world which apparently has not evolved a lot in the recent past. People show a lot of interest in oAW and Eclipse Modeling techniques.

Yesterday we had a very vivid gold fish bowl discussion on the evolution of DSLs. Many of the emerging problems seem to be resolvable by better tooling. That just convinced me that we are working on the right topics in the current development of Xtext and oAW5.

Well, of course there are still a bunch of people around promoting MDA with all the UML and OMG stuff. It appears to me that simple things have a tendency to become rather complicated with that approach.

Looking forward to our hands on workshop on Eclipse Modeling tools tomorrow.

New Article on Textual DSLs with EMP

Peter, Sven and me, we have composed an Eclipse article on how to create your own textual DSL using tools from the Eclipse Modeling Project (EMP). It covers the definition of a grammar using Xtext, generating, running and customizing the DSL editor, adding constraints with Check and generating code with Xpand. You can find it here.

We are convinced that the described approach one of the most pragmatic ways of designing DSLs and implement code generators. If you have just a little bit of experience with the described technologies, creating your own external DSL becomes nearly as natural as writing Java code.

Tuning ELists

Just solved a serious performance problem. I programmtically constructed a rather big EMF model. It took ages so I started a profiler: Most of the time was spend in the BasicEList.contains(EObject) method. 

This is due to the fact that the corresponding EReferences have the unique flag set to true. EMF makes sure each element appears only once in the list of that reference. This is good, but performs poor for big growing lists.

As I construct the model from scratch I can make sure there will be no duplicates. So instead of

parent.getFeature().add(child);

I cast to BasicEList and call

((BasicEList<EObject>) parent.getFeature()).addUnique(child);

In my case, that reduced the execution time to a fifth !

Testing Trees

Working on parsers a lot recently, I have to write quite a bunch of tedious unit tests. Each of these tests analyses an EMF AST model which is the output of the parser. It checks if all nodes are at the right location and if all properties are set correctly. The tests look awful and debugging is a nightmare.

Using Xtext, it is quite easy to create a DSL for tree comparison. I can now describe expected tree results as

Extension {
name=Identifier(value='foo')
params=[
DeclaredParameter {
name=Identifier(value='this')
type=Identifier(value='Object')
},
DeclaredParameter {
name=Identifier(value='that')
type=Identifier(value='Object')
}]
}

where Extension, Identifier and DeclaredParameter are EClasses, name,params and type are EReferences and value is a attribute.

Writing such a DSL and an interpreter doesn't take you a day and will save you a lot of time and mental sanity in the future.

Converging Model Editors

Yesterday, Sven implemented an EMF Resource that serializes its content in Xtext format. We combined it with a graphical editor and the new EValidator adapter for oAW check. Generating everything, we finally got three synchronized editors all showing different representations of the same resource: Graphical, in Xtext and in an Ecore tree. Even complex changes in one editor were automatically transferred to all other editors on save and two of the editors even used the same checks for validation. 

That really rocked.

And it shows how great EMF and oAW really are. In the future, it should be easy to write DSLs with mixed representations, e.g. a graphical part for the element connections and a textual part for the details.

I am really looking forward to work on a closer integration of  oAW and EMF. There's so much potential. 

Advanced GMF

Having collected about two years of experience with Eclipse's Graphical Modeling Framework, I am now trying to summarize what could be improved or added to the framework. These are my favorites

1. Support for a singleton editing domain (keep all semantic and diagram resources in the same resource set)
   
2. Support for non-canonical diagrams (multiple diagrams for the same semantic model)
   
3. Enable the OpenDiagramEditPolicy (linked diagrams)

Most of these issues can be implemented without touching GMF runtime code, i.e. by means of aspectual template changes and extensions. But as these are really fundamental and reoccurring topics, I'd rather see them as base functionality inside the original framework. Maybe I can push the GMF project in that direction?

Here it is...

Finally, web 2.0 has reached me. So here is my new blog.