News and tips on Xtext

Review of the second edition of Implementing Domain-Specific Languages with Xtext and Xtend

I am a proud owner of the first version of this book and I intended to buy a copy of the second edition at some point. So when I was contacted by the publisher to write a review of the second edition I was very happy to accept the offer. Thank you to the author, Lorenzo Bettini, for listing me as a possible reviewer of his work!

What I was happy to find in the book

In a few words: precise answers to advanced questions. A new chapters named Advanced topics is what I wanted to see, sure, but I am also very happy to have clear explanations on using the index or how to check for duplicate across files. The specific chapters on testing and continuos integration are also great to have in this book, in my opinion.

I think this book is enough to go from knowing nothing about Xtext to build reasonably complex projects.

The best way to use this book

I think that the best way to use this book for a newbie is to complement it with other books about language design or specifically on DSLs. You may want to check the list I wrote here.

For the most advanced users you will have unfortunately to learn much more about EMF. You may have to read on of the most boring books ever written: The Eclipse Modeling Framework. The thing is that you can start and write a few Xtext projects without understanding much about EClasses and EResources but eventually you will find some problem for which you will need to learn about the foundations on which Xtext is built, and that means learning EMF.

The things I did not like

The things I do not like have nothing to do with the book per se, which is very well written, clear and amazingly helpful for the poor soul fighting with Xtext. There are things I do not like because I do not like them in Xtext.

One of these things is Xtend: I do not like to have to deal with yet another “improved Java”. Of all of them I would just pick Kotlin and use it all over the places. I understand that Xtend was a good idea when it was started but now Kotlin seems a better idea. I am perfectly aware that this is just my personal taste and nothing objective or decisive. It is just that Kotlin seems to me a better language and a language with more support. The chapter on Xtend has just the fault of reminding me the existence of Xtend. On a more objective note you will need to at least understand Xtend if not being enthusiastic about its existence, so it makes sense for that chapter to be part of the book.

What I would like to see… in the next edition

For newbies I would love to see a couple of extra chapters on language design. For me and for many others Xtext was the “gateway drug” to Language Engineering. By adding some guidance for the young language engineers out there this book could be a rich and complete introduction to Language Engineering. It could give them all they need to be introduced to DSLs and building something real. Without those chapters they have all the technology stuff they need to get started but they are missing a few pieces like “when should I build a DSL”, “what I should use a DSL for”, “what kind of execution models can I consider”, etc.

People who instead have experience with Xtext could like to hear a lot more about the new targets: IntelliJ IDEA and the web. I am sure the Xtext contributors have done an incredible job making almost transparent to target Eclipse, IntelliJ or the web but I have the suspicion that there are the occassional differences here and there. I would be happy to read more lessons learned on using these new targets of Xtext.

I own the first version, should I buy the second one?

This is a very difficult question to answer. It would probably require an in-deep comparison of the two books, so I will give a very approximate answer instead: if you are a professional using Xtext as part of your job you should definitely buy the second edition. Xtext evolved significantly and getting the updated examples is worthy spending a few tens of euros/dollars. Also, if you are like me you would have worn off your first copy so it makes sense to upgrade 🙂

If you are a casual user of Xtext instead, well, you can try not being stingy and buy the second edition anyway. After all it will save you from the occasional headache of trying to make an example work with an API that is slightly changed in the meantime.

The second edition contains circa 70 pages more and a couple of extra chapters: Advanced topics and Conclusions.


When I started using Xtext I hit a wall: there was very poor documentation and an unfriendly community. My questions on forums went unanswered, my bug reports ignored and I was left puzzled. I had to learn the hard way and I could not see any alternative to do. Over time some more tutorials come up, for example from Lars Vogel, there was a huge work on improving the documentation (my eternal gratitude to the people who spent their energy on that!). There was still a missing piece and it was the first edition of this book. I think it is making a difference to have it and the second edition is very welcome. I hope the Language Engineering community will follow the example of Lorenzo and provide more books like this one.

Interview with Jan Köhnlein on TypeFox, DSLs and Xtext

Jan Köhnlein is a leading expert in DSL design and an Xtext committer. After obtaining his PhD from the Technical University of Hamburg he worked for companies very well known in the modeling field: Gentleware and Itemis. Recently he founded TypeFox together with Sven Efftinge and Moritz Eysholdt.

I thought it was a good moment to ask him a few questions about his new venture. Of course it is also a great possibility to ask him about his views on DSLs and the future of Xtext

About TypeFox


Can you introduce TypeFox and tells us more about what services you offer?

TypeFox is a software company focussed on development tools for software engineers and domain experts. As the leading company behind the open-source frameworks Xtext and Xtend, we have great expertise in language engineering, domain-specific languages (DSLs) and tool construction. TypeFox offers all kinds of services around these topics, such as professional support, projects, consulting and training. Our office is based in Kiel, (Germany) at the coast of the Baltic Sea.

How were the very first months at the new company?

TypeFox was founded in January 2016 by Sven Efftinge, Moritz Eysholdt and me. It has been and still is an exciting experience. None of us had led an enterprise before, so there were a lot of new things to learn in addition to getting the company going financially. But we managed to gather a team of very skilled programmers and thanks to the good visibility of the Xtext project we did not have problems to find customers. All in all we had a very successful start. So successful that we plan to grow further.


Are your typical customers already aware of the potentialities of DSLs or do you have to do a lot of evangelization?

Most of our customers choose us because they need Xtext experts, so they are already convinced of the DSL approach. But we do evangelize at conferences, and community gatherings and by writing articles for magazines or online portals.

In your experience what kind of customers are more willing to embrace DSLs? Does it depend on the size of the company or the domain?

As all kinds of abstraction techniques, the DSL approach needs a certain problem size to pay off. Even though Xtext is pretty lightweight for a language engineering framework, you would not create an entity DSL for just a handful of entities. But for a few hundreds you would. So yes, the problem size matters.

Company size does not matter that much. Bigger companies are more likely to have many domain experts, who are not necessarily software engineers, like mathematicians in an insurance company. Those experts can be more directly involved in the software development when they can capture their knowledge in DSLs.

DSLs seem to me more widespread in Europe than in the US: is that true for you? In which countries do you see them more used?

From my former experience, the development in the USA has been more focussed on getting things shipped, while in Europe and especially in Germany we have spent a lot of time on the architecture. Both approaches have pros and cons, but the latter mentality is for sure more susceptible to the DSL approach. Currently we have about as many customers in Europe as we have in the US, so they seem to be converging.

Have you seen any change in the number of DSLs adopters in the last years? Do you think they are going to become more common in the near future?

The basic idea of DSLs is pretty old, and there have always been phases of hype and decline. I see that DSLs have become mainstream in certain areas like enterprise application development, and some industries, like automotive in Germany, even cannot do without them anymore.

What are in your opinion the main issues to adopt DSLs?

Technically, DSLs raise the tool stack. It is not always clear whether this overhead is worthwhile, and many developers are skeptical about that for good reasons. And of course not every programmer is a good language designer.

The other issue is that there is scaffolding: Many developers ask why they should write a code generator for getters and setters, XML mappings or Maven poms if their IDE or web framework generates them on demand. It is not always easy to convince them that it is more sustainable to capture the model in a DSL and write a code generator that can be run repeatedly and can be fine-tuned to the specific needs of the actual project.

Do you work more on DSLs intended for developers or for domain experts? Are they very different?

We currently develop a bit more technical DSLs than business DSLs. This may also be due to the fact that Xtext had been available for Eclipse only, whose look and feel often  scares non-developers off. Since 2.9 you can also generate a web editor for your DSL, and this is where many business DSLs live.

From a language point of view, the main difference is syntax, where developers accept a program like text notation, while many business experts prefer forms, tables, diagrams and prose.

On Xtext


I think that most newcomers to Xtext find the learning curve very steep, probably because of EMF. The quality of the documentation on the official website is very high, especially compared to other Eclipse projects but is there anything else you think the community could do to help people to adopt Xtext?

Thanks for the compliment, but documentation is always something that can be improved. Since Xtext is hosted on Github, it should be very easy for community members to submit pull requests for corrections. And luckily there is the book by Lorenzo Bettini, which is an excellent addition to the official docs. If you have an interesting project based on Xtext, an entry in the community section on the Xtext homepage is also just a PR away. Other than that, we have a very vivid forum where you get answers to your questions very quickly which is also driven by the work of the community.

You and your team are contributors to Xtext and you have an amazing experience with it. Can you tell us a bit about what is going on with Xtext and what interesting things are coming in the future?

We definitely plan to invest more in web support. One part of that is to integrate Xtext with Eclipse Che. Sven is going to talk about that at EclipseCon France 2016. In addition we are going to polish the new features added in 2.9, such as IDEA, Gradle and Maven support, as well as the new generator architecture.

One big feature Xtext got recently is the possibility to generate editors for IntelliJ and for the web. How mature is this feature? Is it helping to attract new Xtext users?

IDEA support is ready to be adopted by the users. Unfortunately, we did not get too much feedback so far. We hope that we are going to get more in the future.

Web support is working fine as well. But as there are a plethora of web application architectures, it will be interesting to use it in more projects and find out where we have to make it more generic or specific.

Xtext is about textual notations but models can support other visualizations (using GEF or other tools). What are your thoughts on combining graphical notations with Xtext? I remember reading a first post from you in 2009 and you kept writing on the subject (a more modern approach is presented here). Is it something you do often? Is it effective?

As Xtext is based on EMF like most graphical frameworks from the Eclipse world, the integration seems to be quite straight forward. But the problems emerge from a different understanding of transactions and object identity. The result will be strange glitches and bugs in the integrated tool.

This is why I advocate graphical views on top of Xtext, that only read the model. With FXDiagram you can do that pretty easily, and get a very modern diagram editor on top.
My colleagues Miro Spönemann and Christian Schneider have both worked on the KIELER project before, so you will probably see more contributions from TypeFox to the graphics community in the future.

By the way, we have a customer project where we integrate a textual DSL editor into a table, which was not easy implement for exactly the same reasons mentioned above, but works great now.

Final thoughts

Xtext is probably the most mature and complete system to create textual DSLs, however there are other “Language Workbenches” available. I am thinking of Jetbrains MPS, Rascal, Acceleo and others. What do you think of these alternatives? Any competitor I am missing? Any feature you think Xtext should get or cases in which an alternative tool is the right solution?

Ranting on competitors is not my style, but it is hard to find an alternative to Xtext that is as powerful, extensible and mature, does not lock you into a closed world of specific development tools, is open-source and backed by companies that provide professional support.

Is there anything else we forgot to discuss?

I just want to say thank you to our team, to all committers and supporters of the Xtext projects and to the community. You made Xtext what is is today.

Finally, what is the best way for customers interested in Xtext consulting to get in contact with TypeFox?

Write us an email to, or bump into us at conferences, like EclipseCon, JAX and others.

Apart from that, we are hiring. So if you know any good software developers who want to join our team, spread the word!

If you are interested in joining TypeFox visit

Jan Köhnlein’s blog

I am spending some time perusing the Jan Köhnlein’s blog, a guy working at itemis and involved in the development of openArchitectureWare: