Xtend Extends Java

| by Alex Blewitt 2 Followers on Jun 27, 2012. Estimated reading time: 6 minutes |

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.String or java.util.Collection API.

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.

What do you think of Xtend?

Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

really interesting

Congratulations, I hope that the project will go forward. He has very good conditions.

Especially it would be good to have more references, and examples

ps: the link to the project is wrong

Not convincing

A lot of effort when there is Scala offering much more.

They should stay at building tools, adding a language of their own is not smart and useless.
Like SWT, not needed

If I want better than Java there is already many much better alternatives.

Re: Not convincing

Serge, you always make a step forward, and then two steps back trying to understand these things. No, not everybody that is looking for an alternative on the JVM is going to use Scala. One of these days you might be able to look beyond your own personal preferences.

Re: Not convincing

Dan, are you ever going to question why things are done ?

Creating a new language is not a sport.

What is this new language bringing ?

I mentionned Scala only because they compared themselves to it.
They are not even close, neither are they from many other alternatives.
Granted they are a very young language, but why ?

And pushing support for this language on the most used java tool is really disturbing.

I will make a deal with you, I will look beyond my preferences as long as you do question the tools that are coming out, it is not because it is available that it should be.

Too little too late

A few years ago, I would have said nice, but now I'll stick with Groovy.
The comparison with Groovy is outdated, certainly since the 2.0 release:
- IDE support is great, especially in Intellij
- Groovy now offers the choice between static and dynamic type checking
- The performance difference with plain Java has become really small and is rarely an issue.

Grtz,
Houbie

Re: Not convincing

Dan, are you ever going to question why things are done ?

Did you do that yourself when you asked that question? To work on Scala, which you brought to the conversation, there are many reasons for adopting Scala. Also there are many reasons not to. Language adoption for starters. I wouldn't care personally, and I would use it w/o hesitation. But some organizations might object, and will object, for the right and/or wrong reasons.

From my experience in trying to get teams and organizations to adopt new technology, it seems to me that it is a lot easier to adopt something like Xtend than Scala. Which has the greater technical merit is of no consequence. Technical merit is just one of the many factors (logical and illogical) that take place in an organization. Something like Xtend is intended to serve as an alternative where Scala (or anything that is different enough from Java or that carries a separate library or whatever.)

Creating a new language is not a sport.

That is true. But it does not follow from it that their implementors don't know what they are doing. After all, that has been the same argument wielded against the developers of Scala, Groovy... hell even Java itself.

What is this new language bringing ?

Syntactic/semantic power beyond what Scala or Groovy provides? Nothing.

A different path for adoption of something different/better than Java? With much better development/debugging integration with Eclipse, with language closer than the familiar one (but with, supposedly, less clunkiness)? Certainly.

I mentionned Scala only because they compared themselves to it.

And what's wrong with that? Scala, by its own right, is the rule by which new JVM language development are to be measured. So by necessity, any JVM language must compare itself with Scala, and Java.

They are not even close,

Nor do they need to. The majority of developers won't care about, say, Case classes (which I love... and I'm just bringing an example.) Less boilerplate and support for lambdas, that's what people salivate for. Whichever language that provides that with the least deviation from the familiar Java syntax, the better it will be for some, if not many.

neither are they from many other alternatives.
Granted they are a very young language, but why ?

For the same reason every other alternative was created in the first place. Let things sprout into existence, and let the chips fall where they may. It's not like they are taking effort or budget away from you or something. And if that new thing on the block chips away at the adoption of Scala, Groovy, Fantom or whatever that comes to mind, maybe then, there was something of value in it.

And pushing support for this language on the most used java tool is really disturbing.

You don't have to use it. Characterizing it as "pushing for it" is a bit of a hyperbole for the sake of please-think-of-the-children rhetoric.

I will make a deal with you, I will look beyond my preferences as long as you do question the tools that are coming out, it is not because it is available that it should be.

That is a silly statement. Adoption, combined with pros and cons (and laws of unintended consequences), the cost of it, the ROI of it, that will determine what should or should not be implemented. You can't pontificate what should or should not exist from a vacuum.

Let them implement it, and let people judge for themselves what should or should not exist. It is good to offer criticism, but to question wholesale the development of a new tool for argument's sake, that's silly and arrogant.

If that type of position were true, we wouldn't even have Java ( I distinctly remember that argument when Java first came out.)

Re: Not convincing

And pushing support for this language on the most used java tool is really disturbing.

Serge, why do you have such a hard time understanding that you don't have to use this? Why are you so disturbed that other people are doing things differently than you would?

I will make a deal with you, I will look beyond my preferences as long as you do question the tools that are coming out, it is not because it is available that it should be.

Speaking of disturbing, that's a pretty disturbing statement. What do you mean "...that it should be". Is there suppose to be some commission setup to tell developers what they can and can't do? Geez man, stop getting your panties in a bunch about things you don't like. Just ignore it. How many years have you been playing this one trick pony? At least it wasn't a Ruby article.

Re: Not convincing

I see this as a big waste of ressources, but if you are ok with it I have nothing to add.

Re: Not convincing

How can I not be "OK" with that? What am I suppose to do, call/email/show up at their doorstep the developers of Xtend and demand that they stop? Serge, I think it's a big waste of time that you're using Scala, and I think I'll just keep on on saying that....;)

Re: Not convincing

Re: Not convincing

That's hilarious coming from you Serge. Serge, I demand you start using Ruby! ;)

Re: Not convincing

I would use XTend before, but then I might miss JCobol or JAda

Good effort but...

Firstly, Java 8 will get lambdas so the timing conflicts a bit.

Secondly, lambdas are essential but languages such as Scala, F# (even C#) offer much more. Perhaps in another 10 years Java programmers will discover the need for those other features...

Re: Good effort but...

Faisal, I am happy to see I am not the only one here that does not see the need for this language.

What you said seems right to me.

Re: Not convincing

Hi Serge,

first of all, coming from the modeling world, I can see your point raising the question for the need of a new language. In the UML world, a lot of companies implemented basic functionality again and again without adding customer value. I think it is a valid question to ask if we need another language. I think the market will decide. However, for me personally, the interesing aspect of Xtend is not that it is an easier Java (which actually seems to attract many developers. If you see the feedback that it gets, it seems to have found a "market gap" between Java and other languages).

One of the major interesting points is the infrastructure that Xtend is built on and the new features of that infrastructure that the devlopment of Xtend has brought with it.

Along with Xtend, Xtext and Xbase now easily allow for integration of complex expressions in your own tools and domain specific languages (DSLs), including compiler, interpreter and now even debugger in your own languages.

And this actually saves resources: It is now so much easier for developers of tools to add languages to their own tools (e.g. modelling, BPMN, requirements, AUTOSAR) because of the features and the good integration to the Eclipse framework. Yes, the interview features the stand-alone capabilities. But there is more to Xtend and its infrastructure than just being a new language with a compiler. In my POV its the Xtext/Xbase/Xtend combination that makes the new release a powerful set of tools - but that does not stop anyone from just liking the base language.

Regards,

Andreas

Re: Not convincing

I suppose I can see the use for the tools provided.

But for the language, I see no use. The purpose is probably to promote the rest of the tools as you seem to imply.

As far as the feedback it gets, I am alone to know about it at work, so I see no effect so far, but it is very early.

To me a lot of alternatives are much better. So I won't use it and certainly won't recommend it.

I would have preferred that the effort put in this language to be used to improve support on the current alternatives, as with Cutlin from IntelliJ it is the syndrome of not invented here. They had to come with their own language, needed or not.

So I have to be grateful for the tools.

Re: Not convincing

Hi Andreas meta-programming (which xtend provides) is a very useful feature to have in any platform. Some 'base' languages provide meta-programming out of the box, which is much cleaner. See for example, websharper.com for how this feature is being leveraged in F# to generate javascript for rich web applications.

Also note that the entire application landscape is changing because of cloud, rich web, mobile and 'apps' (IOS, WinRT). Increasingly, Java/JVM alone is not enough so many programmers will be forced to learn other language(s). Hopefully this will engender a polyglot mindset in the community and greater acceptance of other languages by Java programmers.

No traits

Xtend does not have traits or mixins and they are not mentioned on the roadmap. This is the big thing still missing in Java. JDK8 will have lambdas as well, anyway. Groovy has @Mixin and @Delegate. Then I see no reason why to change from Groovy to this new language. Groovy with @CompileStatic is in performance about 10% slower than Java (using Havlak's benchmark). AST transformations in Groovy are awesome and only matched by macros in Scala. Xtend does not even mention them.
Close

by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

18 Discuss

Login to InfoQ to interact with what matters most to you.