Xtend is a newcomer to the JVM landscape and is built on top of the Xtext language development tool, giving it great integration with the Eclipse IDE. For you Eclipse fans out there, the foundation’s Xtend and Xtext projects will not offer such a tight connection to other IDEs, but since the majority of the Java world uses Eclipse, many will not mind.
We covered Xtend in the RebelLabs report entitled The Adventurous Developers’ Guide to JVM Languages, and it’s being positioned as “faster that Groovy, simpler than Scala and incorporates all the benefits of Java”. We spoke with Sven Efftinge, creator of Xtend, about the language, the JVM and the coding life in general.
Interview with Sven Efftinge, creator of Xtend.
RebelLabs: Hi Sven, thanks for joining us. Could we start with a three-sentence pitch about Xtend?
Sven: Xtend is a statically typed programming language which is translated to readable Java source code. It supports existing Java Idioms and is designed to work even better with existing Java APIs than Java itself. Xtend is a ﬂexible and powerful tool to build useful abstractions and comes with advanced Eclipse IDE integration. It’s an open source project at Eclipse.
RebelLabs: How did you come up with the idea of a new programming language for JVM?
Sven: The Java ecosystem has many good properties, like the many mature open-source frameworks or the extremely advanced tools. But the language itself is old, rigid and too limiting. Xtend addresses the problems of the Java language holistically. It relies on and reuses the solid foundation of the Java ecosystem but gives you a dense and more ﬂexible syntax.
With Xtend you can ﬁnally write concise code and deﬁne powerful abstractions without switching to a completely different ecosystem.
RebelLabs: What was the programming language that inspired Xtend the most?
Sven: Deﬁnitely Java, as it is the language we know best and have a lot of experience with. Beyond that Xtend borrows features with many different languages, including Python, Smalltalk, C#, Scala and Lisp.
RebelLabs: Why did you make the decision to translate your Xtend code into Java code, rather than directly to bytecode?
Sven: First, it lets you use Xtend with tools that require Java source code, such as GWT. Also it allows for reusing the fast and optimizing Java compilers we have. Xtend code usually runs as fast as the equivalent but much more verbose Java code.
By far the biggest advantage is transparency. Having your Xtend code translated to Java source lets you understand what the Xtend compiler actually does in detail. Java is well known and trusted, translating to it gives people the needed conﬁdence. This is especially helpful when you are new to the language and want to learn how a certain snippet of code is translated and how the compiler works under the covers. You can always just have a look at the Java code.
The Eclipse-based Xtend IDE even provides a so called “Generated Code View” that shows the Xtend code and generated Java code side-by-side. You can see through selections what parts were generated from what Xtend code on a very ﬁnegrained basis.
Also during debugging you can switch between debugging through Xtend or Java source code. Xtend is generated to what I call ‘statementisized’ Java code. Long, chained expressions which are typical for a functional programming style get translated to multiple statements with synthetic variables. So you can step over the individual expressions and inspect the intermediate results.
RebelLabs: Are you excited about the features (lambdas, defender methods) in Java 8?
Sven: Yes, they are deﬁnitely needed and a good step in the right direction. Xtend will use Java 8 as an optional compilation target to improve the generated code. Java 8 lambdas are semantically very similar to the ones from Xtend. The new stream API for instance works nicely with Xtend without any further ado. In fact it works even better from Xtend than from Java 8. I’ve written a short blog post on that http://blog.efftinge.de/2012/12/java-8-vs-xtend.html :-). Still I prefer the Guava APIs since they are more convenient and readable than the Java 8 stream API.
The defender methods are a good addition as well, although I don’t like the syntax with the ‘default’ keyword. They struggled with the different default visibility of interface and class methods. I think they are trying to make a signiﬁcant syntactic distinction so people don’t confuse classes with interfaces. In Xtend the default visibility of methods is the same for classes and interfaces that isn’t a problem here.
RebelLabs: What are the features you would like to see in Java.next?
Sven: That would of course exactly be the features you see in Xtend plus some you will see in the near future. :-)
RebelLabs: How hard is it to get Java interop working for Xtend? What are the main challenges?
Sven: Many JVM languages take Java interoperability just as the plain possibility to call out to Java functions somehow. With Xtend, we take Java interoperability seriously since we want to leverage existing Java APIs. Xtend doesn’t bring its own big standard lib, but relies on the JDK and Google Guava. Both are well written and mature Java libraries and we wouldn’t dare to rewrite those since they are already very good and solid. There are so many more interesting things that we can work on :-)
The basis for 100% interoperability is the exact same type system. Xtend doesn’t go overboard and introduce all kinds of new types. Instead it’s 100% the same as in Java.
Things like generics or auto boxing which 10 million Java devs are used to, work exactly as in Java. Also method resolution and method overloading are exactly like in Java.
But Xtend goes further than that. We have carefully analyzed and identiﬁed commonly used Java idioms and made sure they are well supported by Xtend. This starts with the obvious support for JavaBeans properties and doesn’t end with how you pass event handlers. Also with extension methods you can add new methods to existing types easily. Therefore Xtend is often even more interoperable with existing Java APIs than Java itself.
RebelLabs: If you had an opportunity to design Xtend from scratch again, what would you do differently?
Sven: Not too much. It’s a relatively young project and we are very careful with the features and APIs we add.
RebelLabs: Some JVM languages seem to have a bit different approach to the “billion dollar mistake” (ie null values). What is the rationale for Xtend to approach this?
Sven: Today Xtend supports the safe operator and the elvis operator, to navigate nullable types easily. Also extension methods and the switch expression help to handle null pointers. Then there is the Optional type in Guava and soon a similar one in Java 8.
That said, we plan to work on nullable and non nullable types, but it won’t compromise Java interoperability.
RebelLabs: Is there a particular aspect of Xtend you would like to emphasize?
Sven: I’m very excited about a new feature called Active Annotations. It is basically a much better annotation processing. With that you can can participate in the translation process from Xtend to Java code. For instance the @Property annotation which generates JavaBean getters and setters for an annotated ﬁeld is an active annotation.
This is not new and is basically Lisp macros brought to the Java landscape. The speciality is that it is very easy to build and deploy your own active annotations and that it works nicely with the type system and therefore Eclipse. The IDE is 100% aware of any changes you do through active annotations and they become instantaneously available as you hit save. Also you will be able to do additional compiler checks, add default imports and even provide quick ﬁxes. Of course it is a huge advantage to be able to look at the generated Java code as it let’s you easily understand what your processors do.
I think this has big potential and I’m already having a lot of fun with it.
We are releasing a new version of Xtend on March, 20. It will contain a provisional version of the Active Annotation API with which you can already do very cool things.
RebelLabs: Programming language design is about compromises. Is there any feature that you had to drop because it didn’t ﬁt your constraints or because of JVM limitations?
Sven: There are thousands of features one could add but it has never been a compromise to leave them out. If you add a feature you can never remove it again. It’s important to grow a language carefully and slowly – maybe not as slowly as Java :-)
RebelLabs: It looks like that most of the recent JVM languages take advantage of static types. Have statically typed languages win the race?
Sven: Advanced IDEs like Eclipse, Netbeans and IntelliJ need static type information to work well. Most of the time static types don’t get into your way and with the kind of type inference we have in Xtend you rarely have to write them, where they don’t contribute to the readability of the code.
That said, sometimes you don’t want to use static types, which is why we have a reﬂection API in Java. I think a dynamic type like they have in C# is a good idea. Also the methodmissing feature most dynamic languages have comes in handy at times.
RebelLabs: How do you see the JVM languages landscape in 5 years?
Sven: I have no idea whether there will be more languages but I think regarding the platforms there will be much more uses of Dalvik. Android is going to be used in the embedded industry much more and even gaming platforms start to use it. There’s deﬁnitely a bright future for Java.
I believe that Java will remain the dominant language on Dalvik and the JVM. And I hope it improves, I especially look forward to project Jigsaw. Xtend will remain staying three steps ahead of Java, since there is much less legacy we have to carry with us.
RebelLabs: In your opinion, how important is the toolset for the programming language (in respect to Xtend)?
Sven: A slick editing experience is super important. Things like content assist, navigation and refactorings are crucial. Also auto formatting, quick ﬁxes and automatic management of import sections is something I don’t want to live without anymore. But it has to be fast and slick. Also as with languages I don’t like tools which are overly polluted with bells and whistles.
But people have different workﬂows and preferences, so Xtend can of course be used from the command line with e.g. Maven or Ant. Especially the Maven support has been improved for the upcoming release. We are also going to work on supporting other editors and IDEs.
RebelLabs: Can you suggest any good reading for the wannabe language designers?
Sven: Yes, source code :-) Seriously, reading a lot of code in different languages deﬁnitely helps. I also like to read books and speciﬁcations about programming languages.
My team and I have been working on Xtext, a language development framework, for a couple of years now. Since than we have implemented and seen many different languages, which has taught us a pretty good understanding of what sound language design is. I think doing is at least as important as reading.
RebelLabs: Sven, always a pleasure speaking with you. Thanks for your time and contribution to the report!