Together with the release of Eclipse Juno, the Eclipse Foundation is proud to announce the release of Xtend, a Java-compatible language with lambdas and yet full compatibility with the Java runtime. Xtend is built upon Xtext, a suite of DSL libraries and plugins for generating editors.
Unlike Scala, Ceylon or Kotlin, Xtend doesn't need its own separate bytecode compiler. Instead, Xtend source files are translated into Java source files, which are then compiled with the regular Java compiler. As a result, Xtend can be used as a development time translation tool that generates Java for use in a standard Java project, or it can be used as source models that are used to generate Java source files at compilation time.
There are two ways that Xtend can be compiled; via an Eclipse builder (the same way that Maven projects are embedded into Eclipse), or as a Maven plugin which can be used in headless builds. Whether the generated Java source should be checked in is largely a matter of personal taste and practicality; organisations that have yet to buy into Scala may find the approach of Xtend a refreshing change which allows for incremental transformation.
Xtend also ships with some functional libraries and extension methods for existing classes. Unlike Scala, which wraps objects in other types through implicit conversions, Xtend uses compile-time translation to call static methods which take the target as the first argument, much like Java's Collections.sort() method. However, unlike Java, the code can be invoked as list.sort() which translates to Collections.sort(list). Although extension/defender methods will be available in Java 8, which can add new methods to classes implementing an existing interface, Xtend allows you to add methods to either existing interfaces or existing classes in the current Java runtimes.
Finally, Xtend also adds an extended switch statement with type guards (slightly less powerful than Scala's match statement, but with a similar behaviour) as well as proper dynamic dispatch for methods based on their runtime type instead of their compile type.
InfoQ caught up with Sven Efftinge, creator of Xtend, to find out more about the project and its creation, starting with a question on why Xtend was created:
Sven Efftinge: Java has many good qualities, like the exceptionally great tools and the vast amount of high-quality open-source software. Unfortunately, Java's syntactic inflexibility and its ceremonial style mitigates the advantages and makes some of us even switching to a whole new world like Scala or Clojure.
I wanted to be able to stay in the Java universe without being forced to write and read all the boilerplate. I wanted a Java which is as expressive as Python or Ruby but with Java-like IDE support and ZERO interoperability issues. The language should even reuse Java's syntax and its concepts as much as possible so it's easy to learn and doesn't cause any trouble when mixed into an existing Java project. Xtend is meant to be a readable and expressive way to write Java applications – think CoffeeScript for Java.
InfoQ: How does Xtend compare to Groovy or Scala?
Sven Efftinge: Groovy is designed with a similar goal but unfortunately took the short route. Besides limitations in the IDE support, the lack of static typing has a lot of implications on Java interoperability. For instance, overloaded methods are resolved differently in Groovy than in Java, which can be very surprising. The complex meta object protocol is not only very hard to understand and to debug, but is one of the main reasons for Groovy's bad runtime performance.
Xtend allows to build expressive libraries such as builder APIs and other internal DSLs without trading static typing, performance or tool support.
Scala is an ecosystem on its own with a huge library and its own frameworks. I like many parts of the language although I think the type system is a bit over the top for mainstream development. Xtend is definitely influenced by Scala, but focusses much more on Java interoperability and IDE support.
InfoQ: Can you build Xtend programs outside of an IDE?
Sven Efftinge: Yes, the compiler is 100% independent of Eclipse and can be run in any Java process. Also a Maven plug-in is available.
InfoQ: Whats the backward compatibility like between versions?
Sven Efftinge: Generally only major version increments might introduce API breakage. Published API will be maintained in a backward compatible manner for all other version increments. Some APIs are published using the @Beta annotation, which indicates that they are not yet final so you should use them with care.
InfoQ: Are there plans to create xtend specific libraries or frameworks, or will this happen through existing Java libraries?
Sven Efftinge: Xtend is designed to work extremely nice with existing Java idioms. So most of the time there is not much need for special Xtend glue around an existing Java API. Within the project we concentrate on the bread and butter libraries by adding extensions for standard Java types like
java.lang.Stringorjava.util.CollectionAPI.Some community members have started to work on smaller extension libraries for frameworks like Java FX or Android and I hope to see more of that in the future.
InfoQ: Are there any other Eclipse projects using Xtend?
Sven Efftinge: A lot of code in Xtext is implemented in Xtend and I know that some of the new stuff in EMF is also using it. Also the new and cool Code Recommenders project use Xtend for writing unit tests. Starting with writing tests is generally a good idea.
InfoQ: Do you have to be using OSGi to use Xtend?
Sven Efftinge: No, Xtend has really no runtime dependency on anything other than a very thin library. You can of course use OSGi like you can use any other Java tool, but you don't have to.
InfoQ: Is Xtend compatible with prior Eclipse runtimes?
Sven Efftinge: The plug-in works with Eclipse 3.6 - 4.2. The compiler is not dependent on Eclipse at all.
InfoQ: What's the performance of Xtend like, in comparison to Scala/Groovy?
Sven Efftinge: Xtend translates to Java code without any magic runtime overhead. Its runtime performance is comparable to the one of Java. Of course, as in other languages, it depends on the code you are writing.
InfoQ: Is there a lot of auto boxing or type conversion happening under the hood?
Sven Efftinge: Xtend supports the same primitives and wrapper types as Java does and auto boxing happens exactly in the same situations in which they happen in Java.
There are no big changes in the type system, to avoid surprises and ensure 100% interoperability with Java.
InfoQ: What is so special about "it" and what effect does setting it have on your code?
Sven Efftinge: Any variable named 'it' is implicit similar to 'this' as we know it from Java. So we do not have to write the receiver explicitly when calling a method on 'it'.
Although you can name any local variable or parameter 'it', there are certain situations where you get such a variable automatically.
The most useful example is the shorthand syntax for lambda expressions. In Xtend one can simply write:
myFriends.sortBy[ lastName ]Just for comparison, in Java 8 you would have to write:
myFriends.sortBy( it -> it.getLastName() )
InfoQ: Can you debug an Xtend program?
Sven Efftinge: Yes, the debugger is integrated with the Java debugger, so you can debug seamlessly through a code base containing both Java and Xtend sources. One can even switch between debugging through Xtend or the generated Java code within the same session.
More information about Xtend is available from the Xtend home page, which also explains the language syntax and demonstrates the new features that Xtend brings.
What do you think of Xtend?