Yes. So I started my diploma thesis by rewriting a code generator framework, which was known as “Open Architecture Ware” – I don’t know if anybody knows that anymore. During that phase I built languages to do code generation and I had to build Eclipse plugins for that and I figured out I had to do all these plugin stuff, the Eclipse editor stuff over and over again for the different languages. And one day I thought about how could I simplify this by rewriting all that information from the grammer and I did a prototype for Xtext and then it got quite well received and we founded a project at Eclipse. I founded a nice company called itemis, who is paying me for developing this kind of stuff, together with six smart people and my office in Kiel and that’s how it came.
Ok, so the main difference is that Xtext is not a parser generator framework, I mean it uses Antlr to generate a parser from the grammar but it also generates you a fully fleshed Eclipse editor and IDE integration including workspace, index and all that stuff, also you get quite nice hooks for doing scoping and validation, compiler checks and all that stuff. So there’s a lot more to Xtext than just the parser generator. Also from that grammar it un-parses the generator which does not rely on Antlr but it has been written by us.
3. Antlr has different ways of parsing a document for Xtext or for Antlr?
Different ways?
Alex: You were saying the un-parser.
It’s in un-parser. It’s a serializer. You can parse a text in-memory model and then you can do modification on that model and write it back to text again.
Alex: Ok, so you can parse a document bi-directionally
Yes, the grammar is bi-directional.
Ok, with Xtext a lot of people build these structural domain specific languages like it’s a great replacement for Xml scenarios, like you get better editors and so on, but you have this problem that at some point you want to have expressions in your DSL, if you take Ant or Maven or so, you want to have some kind of expressions to compute values there, and implementing an expression, especially a statically-typed one, is not very simple to do and also they are mostly the same, especially when you are in the Java environment, there’s no need to have different expression languages over and over again, because they are hard to learn and so on. So what we’ve built with Xbase is a library which you can reuse in your simple DSL. So you concentrate on your structured stuff, like services or entities or whatever you have and when you say I want to have methods in my entities then you just say the implementation is an expression, a Xbase expression, and Xtext does all the type analysis and the content assist and the IDE support and everything for you, you just say “Well this is an expression” and everything works.
Yes, in fact we have a very need abstraction there, that is you have your domain specific language AST and you just explain how these maps to a Java model and you put your expression into the scope of that Java model and then the Xtext framework can figure out the scoping rules and everything and links everything for you and it just works then.
Xtend is a general purpose language which is built on top of this library, so in that sense it’s an example, it shows that you can really do production ready stuff with that, with very advanced tool support, but of course that’s not the purpose of the language, to be an example. The purpose of the language is really to have a lightweight tool for the typical Java limitations. So in typical Java projects, you very early hit some limitations where you call out to other solutions like XML template languages or what so ever, so if you are a Java developer, you are a polyglot developer because you have so many different formats involved in your Java project. And I think these really have integration problems, so what we usually do as Java developers is we is we pile tools on top of the problem, if you have a problem in Java, well, write a plugin for Eclipse or whatever or a tool or code generators and all that stuff. So Xtext is a great solution for this code generator stuff, but sometimes it might be a bit heavy-weight, because you have to deploy this extra language and keep it up in sync with your project and so on, so with Xtend you can solve many of these problems with more generically, more in a library approach, so we have both, depending on what you need.
With Xtend we’ve focused on interoperability with Java a lot, so it’s not only interoperable in the sense that you can call out to Java but it should be seamless, so the idea is to have a Java project as soon as you think a certain problem is not very well supported in Java, you could just instead write an Xtend class and it will just match into this, so for instance, the type system which is used by Xtend is exactly the same as in Java, so there’s no difference, no gap. Some user said it like: you’re not thinking in two worlds; so there’s really no integration issue. So that was very important and that’s one important difference. Other than that, we’ve focused on very good tool support from the beginning, because that’s important to Java developers, they are used to that and it’s similar to Scala in the sense that it gives a lot of power to the developer and responsibility so you can design very neat abstractions with it and it’s very different from Scala in the sense that it’s much simpler and because it just lives within the Java ecosystem, no extra library and so on.
We are an Eclipse project, so we take that seriously, we have certain ways of flagging API as provisional and we do so and if it’s not flagged as provisional, it will stay as it is and it will be compatible in the next release.
Yes, but there are some exceptions, they are more things that sometimes we forgot about a certain compiler check, so there is something like a “feature” maybe which was actually a bug and there are two or three occasions where we decided we really want to fix this. So on the source level, you might get an error message which says: Well, you should do it like this; instead on the compiler level it will be compatible.
12. How large is the library, what does it add to the deployment pipe line?
So the Xtend library is a very thin façade to Google Guava and the JDK, it basically only puts extension methods so the very useful stuff from Guava is put as an extension on the cool stuff from JDK, so to say. And this thin library is, I think 49k or so, just a couple of classes and then there is Guava, I’m not sure how big it is, but it’s not too much.
Yes, for sure. With Android you have this limitation that you want to have an application with a very small footprint and with other solutions. I mean most other JVM languages don’t even work well on Android, but if they work they have these big extra libraries, so they usually can’t use the JDK very well because then you can’t use the extra features.
We have fully embraced this kind of programming style, so one key ingredient is that you have a very neat syntax for anonymous functions Lambdas. Xtend has the most concise Lambda expression out there and the other thing is that everything is an expression, there are no statements, so you can nest if and for as well, like in Scala. Also the type inference is very neat in Xtend, so it goes very far and it does so with the Java type system. So a lot of people complain about generics and to some extent for good reasons, but with Xtend you don’t have to care so much because you almost never have to write this signatures down.
Yes, exactly, and even more important, you get good tool support and integration with the Java world, so if you do open call hierarchies or open type hierarchies and rename refactoring, it works across Xtend and Java, just as you expected.
No, we are good participants; we have to being an Eclipse project we can’t use Aspect/J stuff in order to hook into other libraries. We use the possibilities which are available in order to integrate.
Yes. You can only install one version of Xtend as in the plugin, right? But other than that, you can do that and also you don’t have a conflict with JDT, so we don’t change what JDT does.
I hope so. We don’t have concrete plans, we’ve built some prototypes also for bringing Xtext to other platforms, that’s also very interesting, to be able to generate editors for other platforms. We had a short talk in the Orion session today where a colleague of mine is showing how a web editor is generated from a Xtext grammer, so we were working at this kind of stuff but what the Eclipse IDE does for Xtend today, that’s quite a lot and I would love to see other IDEs that have this kind of support for Xtend of course, but yes, it would be cool to have contribution in that direction somehow.
Yes, that’s a very neat cool feature. Think of it as annotation processing done right, more or less, or Lisp macros in a static world. It’s basically a way to enhance a compilation step from Xtend to Java source code. So what you do is you declare an annotation and then you implement a compiler hook, where you can get in the annotated element and you can modify it. So you get something like Java lang class object more or less, but it’s mutable, so you can change the stuff and then it’s generated down to Java code. And the good thing is that you don’t lose the static typing, so the IDE is fully aware of your changes, so for instance if you have an add property for a field you will get content assist for the gathers and setters which have been generated in the background.
It’s for Xtend and Xtend it’s translated into Java source code and Xtext is not Java specific, so you can build almost any kind of language and translate it into any kind of stuff. We have a lot of customers in the automotive industry for instance, where we generate C embedded stuff and so on. But for Xtend, the compilation’s target is always Java source code.
Yes, sure. So you can use a Maven plugin, also the compiler is not Eclipse dependent at all, so you can just call it from command line if you want to, and we provide a Maven plugin to make it easy.
22. What about other build systems there Ant for example and maybe Gradle?
There’s a Gradle plugin, someone from the community built that and Ant should be quite easy but I’m not sure if anybody did that so far.
23. Finally, what’s the future road map looking for Xtend and Xtext?
The future road map is to reduce turnarounds even more so that’s an interesting part and also focus on this compilation thing you can do, so with active annotation that’s one idea but we want to do something similar to Scala macros as well, because we have this cool infrastructure which is very transparent, you get the Java source code, you can read it and so on, that’s quite powerful and other than that we want to make it more performant and add some really slick IDE features and so on, this kind of stuff.
Alex: Sven Efftinge, thank you very much!
Thank you!