Xtend is a statically-typed programming language which translates to comprehensible Java source code. Syntactically and semantically Xtend has its roots in the Java programming language but improves on many aspects:

  • Extension methods - enhance closed types with new functionality
  • Lambda Expressions - concise syntax for anonymous function literals
  • ActiveAnnotations - annotation processing on steroids
  • Operator overloading - make your libraries even more expressive
  • Powerful switch expressions - type based switching with implicit casts
  • Multiple dispatch - a.k.a. polymorphic method invocation
  • Template expressions - with intelligent white space handling
  • No statements - everything is an expression
  • Properties - shorthands for accessing and defining getters and setter
  • Type inference - you rarely need to write down type signatures anymore
  • Full support for Java generics - including all conformance and conversion rules
  • Translates to Java not bytecode - understand what is going on and use your code for platforms such as Android or GWT

Unlike other JVM languages Xtend has zero interoperability issues with Java: Everything you write interacts with Java exactly as expected. At the same time Xtend is much more concise, readable and expressive. Xtend's small library is just a thin layer that provides useful utilities and extensions on top of the Java Development Kit (JDK).

Of course, you can call Xtend methods from Java, too, in a completely transparent way. Furthermore, Xtend provides a modern Eclipse-based IDE closely integrated with the Eclipse Java Development Tools (JDT), including features like call-hierarchies, rename refactoring, debugging and many more.

Hello World

The first thing you want to see in any language is a Hello World example. In Xtend, that reads as

class HelloWorld {
  def static void main(String[] args) {
    println("Hello World")

You see that Xtend looks quite similar to Java. At a first glance the main difference seems to be the def keyword to declare a method. Also like in Java it is mandatory to define a class and a main method as the entry point for an application. Admittedly Hello World programs are not a particular strength of Xtend. The real expressiveness is unleashed when you do real things as you will learn in a second.

An Xtend class resides in a plain Eclipse Java project. As soon as the SDK is installed, Eclipse will automatically translate all the classes to Java source code. By default you will find it in a source folder xtend-gen. The hello world example is translated to the following Java code:

// Generated Java Source Code
import org.eclipse.xtext.xbase.lib.InputOutput;

public class HelloWorld {
  public static void main(final String[] args) {
    InputOutput.<String>println("Hello World");

The only surprising fact in the generated Java code may be the referenced library class InputOutput (src). It is part of the runtime library and a nice utility that is quite handy when used in expressions.

You can put an Xtend class into a source folder of any Java project within Eclipse or any Maven project. If the project is not yet configured properly, Eclipse will complain about the missing library. The xtend.lib has to be on the class path. The IDE will provide a quick fix to add it.

The next thing you might want to do is materializing one of the example projects into your workspace. Right click anywhere in the Navigator view in Eclipse and select New -> Example....

In the upcoming dialog you will find two examples for Xtend:

  • Xtend Introductory Examples contains a couple of example code snippets illustrating certain aspects and strengths of Xtend. For instance it shows how to build an API which allows to write code like this:
    assertEquals(, (40_000.m + / 60.min)
    Also the movies example explained in detail in the next section is included there.
  • Xtend Solutions For Euler contains solutions to some of the problems you will find at Project Euler. These examples are leveraging the whole expressive power of Xtend. For instance Euler Problem 1 can be solved with this expression :
    (1..999).filter[ i | i % 3 == 0 || i % 5 == 0 ].reduce[ i1, i2 | i1 + i2 ]

The Movies Example

The movies example is included in the example project Xtend Introductory Examples (src/examples6/Movies.xtend) and is about reading a file with data about movies and doing some analysis on it.

The Data

The movie database is a plain text file (data.csv) with data sets describing movies. Here is an example data set:

Naked Lunch  1991  6.9  16578  Biography  Comedy  Drama  Fantasy

The values are separated by two spaces. The columns are :

  1. title
  2. year
  3. rating
  4. numberOfVotes
  5. categories

Let us define a data type Movie representing a data set:

@Data class Movie {
  String title
  int year
  double rating
  long numberOfVotes
  Set<String> categories 

A movie is a POJO with a strongly typed field for each column in the data sets. The @Data annotation will turn the class into an immutable value class, that is it will get

  • a getter-method for each field,
  • a hashCode()/equals() implementation,
  • implementation of Object.toString(),
  • a constructor accepting values for all fields in the declared order.

Parsing The Data

Let us now add another class to the same file and initialize a field called movies with a list of movies. For the initialization we parse the text file and turn the data records into Movies:

import java.util.Set
import static extension*

class Movies {
  val movies = new FileReader('data.csv') [ line |
    val segments = line.split('  ').iterator
    return new Movie(, 

A field's type can be inferred from the expression on the right hand-side. That is called local type inference and is supported everywhere in Xtend. We want the field to be final, so we declare it as a value using the keyword val.

The initialization on the right hand side first creates a new FileReader. Then the method readLines() is invoked on that instance. But if you have a look at FileReader you will not find such a method. In fact readLines() is a static method from Google Guava's CharStreams which was imported as an extension. Extensions allow us to use this readable syntax.

import static extension*

CharStreams.readLines(Reader) returns a List<String> on which we call another extension method map. This one is defined in the runtime library ( (src)) and is automatically imported and therefore available on all lists. The map extension expects a function as a parameter. It basically invokes that function for each value in the list and returns another list containing the results of the function invocations. Actually this mapping is performed lazily so if you never access the values of the result list, the mapping function is never executed.

Function objects are created using lambda expressions (the code in squared brackets). Within the lambda we process a single line from the text file and turn it into a movie by splitting the string using two whitespace characters as the separator. On the result of the split operation, the method iterator() is invoked. As you might know String.split(String) returns a string array (String[]), which Xtend auto-converts to a list when we call Iterable.iterator() on it.

val segments = line.split('  ').iterator

Now we use the iterator to create an instance of Movie for each String that it yields. The data type conversion (e.g. String to int) is done by calling static methods from the wrapper types. The rest of the Iterable is turned into a set of categories. Therefore, the extension method IteratorExtensions.toSet(Iterator<T>) (src) is invoked on the iterator to consume its remaining values.

return new Movie (, 

Answering Some Questions

Now that we have parsed the text file into a List<Movie>, we are ready to execute some queries against it. We use JUnit to make the individual queries executable and to confirm their results.

Question 1 : What Is The Number Of Action Movies?

@Test def numberOfActionMovies() {
    movies.filter[ categories.contains('Action') ].size)

First the movies are filtered. The lambda expression checks whether the current movie's categories contain the entry 'Action'. Note that unlike the lambda we used to turn the lines in the file into movies, we have not declared a parameter name this time. We could have written

movies.filter[ movie | movie.categories.contains('Action') ].size

but since we left out the name and the vertical bar the variable is automatically named it. it is an implicit variable. It's uses are similar to the implicit variable this. We can write either

movies.filter[ it.categories.contains('Action') ].size

or even more compact

movies.filter[ categories.contains('Action') ].size

Eventually we call size on the resulting iterable which is an extension method, too. It is defined in the utility class IterableExtensions (src).

Question 2 : What Is The Year The Best Movie From The 80's Was Released?

@Test def void yearOfBestMovieFrom80s() {
    movies.filter[ (1980..1989).contains(year) ].sortBy[ rating ].last.year)

Here we filter for all movies whose year is included in the range from 1980 to 1989 (the 80's). The .. operator is again an extension defined in IntegerExtensions (src) and returns an instance of IntegerRange (src). Operator overloading is explained in section.

The resulting iterable is sorted (IterableExtensions.sortBy (src)) by the rating of the movies. Since it is sorted in ascending order, we take the last movie from the list and return its year.

We could have sorted descending and take the head of the list as well:

movies.filter[ (1980..1989).contains(year) ].sortBy[ -rating ].head.year

Another possible solution would be to reverse the order of the sorted list:


Note that first sorting and then taking the last or first is slightly more expensive than needed. We could have used the method reduce instead to find the best movie which would be more efficient. Maybe you want to try it on your own?

The calls to movie.year as well as movie.categories in the previous example in fact access the corresponding getter methods.

Question 3 : What Is The The Sum Of All Votes Of The Top Two Movies?

@Test def void sumOfVotesOfTop2() {
  val long sum = movies.sortBy[ -rating ].take(2).map[ numberOfVotes ].reduce[ a, b | a + b ]
  assertEquals(47_229L, sum)

First the movies are sorted by rating, then we take the best two. Next the list of movies is turned into a list of their numberOfVotes using the map function. Now we have a List<Long> which can be reduced to a single Long by adding the values.

You could also use reduce instead of map and reduce. Do you know how?

Java Interoperability

Xtend, like Java, is a statically typed language. In fact it completely supports Java's type system, including the primitive types like int or boolean, arrays and all the Java classes, interfaces, enums and annotations that reside on the class path.

Java generics are fully supported as well: You can define type parameters on methods and classes and pass type arguments to generic types just as you are used to from Java. The type system and its conformance and casting rules are implemented as defined in the Java Language Specification.

Type Inference

One of the problems with Java is that you are forced to write type signatures over and over again. That is why so many people do not like static typing. But this is in fact not a problem of static typing but simply a problem with Java. Although Xtend is statically typed just like Java, you rarely have to write types down because they can be computed from the context.

Conversion Rules

In addition to Java's autoboxing to convert primitives to their corresponding wrapper types (e.g. int is automatically converted to Integer when needed), there are additional conversion rules in Xtend.

Arrays are automatically converted to List<ComponentType> and vice versa. That is you can write the following:

def toList(String[] array) {
  val List<String> asList = array
  return asList

Subsequent changes to the array are reflected by the list and vice versa. Arrays of primitive types are converted to lists of their respective wrapper types.

The conversion works the other way round, too. In fact, all subtypes of Iterable are automatically converted to arrays on demand.

Another very useful conversion applies to lambda expressions. A lambda expression usually is of one of the types declared in Functions (src) or Procedures (src). However, if the expected type is an interface or a class with a single abstract method declaration, a lambda expression is automatically converted to that type. This allows to use lambda expressions with many existing Java libraries. See for more details.

Interoperability with Java

Resembling and supporting every aspect of Java's type system ensures that there is no impedance mismatch between Java and Xtend. This means that Xtend and Java are 100% interoperable. There are no exceptional cases and you do not have to think in two worlds. You can invoke Xtend code from Java and vice versa without any surprises or hassles.

As a bonus if you know Java's type system and are familiar with Java's generic types, you already know the most complicated part of Xtend.

Classes and Members

At a first glance an Xtend file pretty much looks like a Java file. It starts with a package declaration followed by an import section and class definitions. The classes in fact are directly translated to Java classes in the corresponding Java package. A class can have constructors, fields, methods and annotations.

Here is an examplary Xtend file:

package com.acme

import java.util.List

class MyClass {
  String name
  new(String name) { = name
  def String first(List<String> elements) {

Package Declaration

Package declarations can look like those in Java. Two small, optional differences:

  • An identifier can be escaped with a ^ character in case it conflicts with a keyword.
  • The terminating semicolon is optional.

package com.acme


The ordinary imports of type names are equivalent to the imports known from Java. Again one can escape any names conflicting with keywords using a ^. In contrast to Java, the terminating semicolon is optional. Non-static wildcard type imports are deprecated for the benefit of better usability and well defined dependencies.

Xtend also features static imports for importing static fields and methods. The semantics and syntax are just like in Java.

As in Java all classes from the java.lang package are implicitly imported.

import java.math.BigDecimal
import static java.util.Collections.sort
import static org.junit.Assert.*

Static methods can also be imported as extensions. See the section on extension methods for details.

Class Declaration

The class declaration reuses a lot of Java's syntax but still is a bit different in some aspects: All Xtend types are public by default since that's the common case. Java's "package private" default visibility is declared by the more explicit keyword package in Xtend. In contrast to Java, Xtend supports multiple public top level class declarations per file. Each Xtend class is compiled to a separate top-level Java class.

Abstract classes are defined using the abstract modifier as in Java. See also abstract methods.

Xtend's approach to inheritance is conceptually the same as in Java. Single inheritance of classes as well as implementing multiple interfaces is supported. Xtend classes can extend other Xtend classes, and even Java classes can inherit from Xtend classes. If no super type is specified, Object is used.

The most simple class looks like this:

class MyClass {

A more advanced generic class declaration in Xtend:

class ArrayList<E> extends AbstractList<E>
        implements List<E>, RandomAccess, 
                   Cloneable, {


An Xtend class can define any number of constructors. Unlike Java you do not have to repeat the name of the class over and over again, but use the keyword new to declare a constructor. Constructors can also delegate to other constructors using this(args...) in their first line.

class MyClass extends AnotherClass {
  new(String s) {
  new() {

The same rules with regard to inheritance apply as in Java, i.e. if the super class does not define a no-argument constructor, you have to explicitly call one using super(args...) as the first expression in the body of the constructor.

The default visibility of constructors is public but you can also specify an explicit visiblity public, protected, package or private.


A field can have an initializer. Final fields are declared using val, while var introduces a non-final field and can be omitted. Yet, if an initializer expression is present, the type of a field can be inferred if val or var was used to introduce the field. The keyword final is synonym to val. Fields marked as static will be compiled to static Java fields.

class MyClass {
  int count = 1
  static boolean debug = false
  var name = 'Foo'          // type String is inferred 
  val UNIVERSAL_ANSWER = 42 // final field with inferred type int

The default visibility for fields is private. You can also declare it explicitly as being public, protected, package or private.

A specialty of Xtend are fields that provide extension methods which are covered in their own section.


Xtend methods are declared within a class and are translated to a corresponding Java method with exactly the same signature. The only exceptions are dispatch methods, which are explained later.

def String first(List<String> elements) {

Method declarations start with the keyword def. The default visibility of a method is public. You can explicitly declare it as being public, protected, package or private.

Xtend supports the static modifier for methods and can infer the return type if it is not explicitly given:

def static createInstance() {
  new MyClass('foo')

As in Java, vararg parameters are allowed and accessible as array values in the method body:

def printAll(String... strings) {
  strings.forEach[ s | println(s) ]

It is possible to infer the return type of a method from its body. Recursive methods and abstract methods have to declare an explicit return type.

Abstract Methods

An abstract method in Xtend does not define a body and must be declared within an abstract class or an interface. Also specifying the return type is mandatory since it cannot be inferred.

abstract class MyAbstractClass() {
  def String abstractMethod() // no body

Overriding Methods

Methods can override other methods from the super class or implement interface methods using the keyword override. If a method overrides a method from a super type, the override keyword is mandatory and replaces the keyword def. The override semantics are the same as in Java, e.g. it is impossible to override final methods or invisible methods. Overriding methods inherit their return type from the super declaration.


override String second(List<String> elements) {

Declared Exceptions

Xtend does not force you to catch or declare checked exceptions. Nevertheless, you can still declare the exceptions thrown in a method's body using the throws clause as in Java.

If you do not declare checked exceptions in your method but they are possibly thrown in your code, the compiler will throw the checked exception silently (using the sneaky-throw technique introduced by Lombok).

 * throws an Exception
def void throwException() throws Exception {
   throw new Exception

 * throws an Exception without declaring it
def void sneakyThrowException() {
   throw new Exception

Optional validation of checked exception is supported, too, and can be configured on the respective Eclipse preference page for the Xtend Errors and Warnings.

Inferred Return Types

If the return type of a method can be inferred from its body it does not have to be declared.

That is the method

def String second(List<String> elements) {

could be declared like this:

def second(List<String> elements) {

The return type is mandatory for abstract method declarations as well as for recursive implementations.

Generic Methods

You can specify type parameters on methods. A parameterized variant of the method from the previous section, could look like this:

def <T> second(List<T> elements) {

Type parameter bounds and constraints are supported and share the same syntax and semantics as defined in the the Java Language Specification

Operator Declarations

Xtend supports operator overloading based on an operator-name-mapping as explained in . To declare an operator one can either declare a simple method using the operator's name or by using the operator directly like in the following:

class Money {
											def + (Money other) { ... }
											def - (Money other) { ... }
											def * (BigDecimal times) { ... }

Dispatch Methods

Generally, method resolution and binding is done statically at compile time as in Java. Method calls are bound based on the static types of arguments. Sometimes this is not what you want. Especially in the context of extension methods you would like to have polymorphic behavior.

A dispatch method is declared using the keyword dispatch.

def dispatch printType(Number x) { 
  "it's a number" 

def dispatch printType(Integer x) { 
  "it's an int" 

For a set of visible dispatch methods in the current type hierarchy with the same name and the same number of arguments, the compiler infers a synthetic dispatcher method. This dispatcher uses the common super type of all declared arguments. The method name of the actual dispatch cases is prepended with an underscore and the visibility of these methods is reduced to protected if they have been defined as public methods. Client code always binds to the synthesized dispatcher method.

For the two dispatch methods in the example above the following Java code would be generated:

protected String _printType(final Number x) {
  return "it\'s a number";

protected String _printType(final Integer x) {
  return "it\'s an int";

public String printType(final Number x) {
  if (x instanceof Integer) {
    return _printType((Integer)x);
  } else if (x != null) {
    return _printType(x);
  } else {
    throw new IllegalArgumentException("Unhandled parameter types: " +

Note that the instanceof cascade is ordered such that more specific types are handled first.

The default visibility of the dispatch cases is protected. If all dispatch methods explicitly declare the same visibility, this will be the visibility of the inferred dispatcher, too. Otherwise it is public. The comparison of the parameter types is performed from left to right. That is in the following example, the second method declaration is considered more specific since its first parameter type is the most specific:

def dispatch printTypes(Number x, Integer y) { 
  "it's some number and an int" 

def dispatch printTypes(Integer x, Number y) { 
  "it's an int and a number" 

generates the following Java code :

public String printTypes(final Number x, final Number y) {
  if (x instanceof Integer
       && y != null) {
    return _printTypes((Integer)x, y);
  } else if (x != null
       && y instanceof Integer) {
    return _printTypes(x, (Integer)y);
  } else {
    throw new IllegalArgumentException("Unhandled parameter types: " +
      Arrays.<Object>asList(x, y).toString());

The code is compiled in a way that a null reference is never a match. null values can be handled by dispatch cases that use the parameter type Void.

def dispatch printType(Number x) { 
  "it's some number" 

def dispatch printType(Integer x) { 
  "it's an int" 

def dispatch printType(Void x) { 
  "it's null" 

This compiles to the following Java code:

public String printType(final Number x) {
  if (x instanceof Integer) {
    return _printType((Integer)x);
  } else if (x != null) {
    return _printType(x);
  } else if (x == null) {
    return _printType((Void)null);
  } else {
    throw new IllegalArgumentException("Unhandled parameter types: " +

Dispatch Methods and Inheritance

All visible Java methods from all super types that are conformant to the compiled representation of a dispatch method are also included in the dispatcher. Conforming means they have the expected number of arguments and have the same compiled name with the prepended underscore.

For example, consider the following Java class :

public abstract class AbstractLabelProvider {
   protected String _label(Object o) {
      // some generic implementation

and the following Xtend class which extends the Java class :

class MyLabelProvider extends AbstractLabelProvider {
   def dispatch label(Entity it)  {
   def dispatch label(Method it) { 
   def dispatch label(Field it) { 

The resulting dispatch method in the generated Java class MyLabelProvider would then look like this:

public String label(final Object it) {
  if (it instanceof Entity) {
    return _label((Entity)it);
  } else if (it instanceof Field) {
    return _label((Field)it);
  } else if (it instanceof Method) {
    return _label((Method)it);
  } else if (it != null) {
    return super._label(it);
  } else {
    throw new IllegalArgumentException("Unhandled parameter types: " +

Static Dispatch Methods

Also static dispatch methods are supported. A mixture of static and non-static dispatch methods is prohibited.

Create Methods

Create methods in Xtend allow to do graph transformation in one pass where it usually needs two passes. That means you don't need to separate a translation from one graph to another in the typical two phases: tree construction and interlinking the tree nodes. You basically just need to write the whole transformation using create methods and the built-in identity preservation will take care of the rest.

Consider you want to create a copy of the following list of persons into a :

Fred Flintstone {
	marriedTo Willma Flintstone
	friendWith Barny Rubble
Willma Flintstone {
	marriedTo Fred Flintstone
Barny Rubble {
	friendWith Fred Flintstone

A function like the following could do the trick :

def List<Person> copyPersons(List<Person> persons) {[copy]
def copy(Person p) {
	val result = new Person() =
	// The following is wrong and results in a stack overflow
	result.friendWith =[copy]   
	result.marriedWith =[copy]

The problem with that code is that we don't track the origins of the created copies. This is the main problem with model transformations. The classic solution is to run the copying in two passes. First we create all instances and then we establish the links. Although it works it results in cluttered and non coherent code. Xtend's create functions handle this problem by introducing identity perservation by tracking the origin of each created instance. Therefore, a create function takes two expressions. One to instantiate the actual object and a second one to initialize it.

def create result: new Person copy(Person p) { =
	// now it works	
	result.friendWith =[copy]   
	result.marriedWith =[copy]

If you do not specify the name of the result variable it is assumed to be the implicit receiver variable it, which can be skipped in feature calls inside the body. Furthermore, you can define the return type of a create function:

def Person create new PersonImpl() copy(Person p) {
	/* it.*/name =
	friendWith =[copy]   
	marriedWith =[copy] 

How it works

In addition to the keyword create one specifies two expressions. The first expression is the factory to create an instance while the second will initialize it further. Prior to invoking the factory expression, a cache lookup is performed to find a previously created instance for the very same arguments. If there is no such instance, the factory expression is evaluated and the result is stored in the cache. Subsequently the main expression (also called the initializer expression) is evaluated. This happens only if there was no previously created instance available in the cache. If that expression in turn calls the create function transitively using the same set of arguments the previously instantiated and cached object is returned. Note that the object is probably currently initialized. That is, its internal state may not yet be available. The lifecycle of the cache is attached to the instance of the declaring Xtend class. That is you can control how long the cache lives by means of Guice.


Annotations are available on classes, fields, methods and parameters. They are prefixed with the @ character and accept a number of key-value pairs or a default value for the annotation property named value. Annotation values that expect arrays can handle single values, too. Value arrays are enclosed in array literals #['first', 'second']. The semantics for annotations are exactly like defined in the Java Language Specification. Here is an example:

@TypeAnnotation("some value")
class MyClass {
  @FieldAnnotation(value = @NestedAnnotation(true))
  static val CONSTANT = 'a compile-time constant'
  @MethodAnnotation(constant = CONSTANT)
  def String myMethod(@ParameterAnnotation String param) {

In addition Active Annotations allow users to participate in compilation of Xtend code to Java source code.

Extension Methods

Extension methods allow to add new methods to existing types without modifying them. This feature is actually where Xtend got its name from. They are based on a simple syntactic trick: Instead of passing the first argument of an extension method inside the parentheses of a method invocation, the method can be called with the first argument as its receiver - it can be called as if the method was one of the argument type's members.

"hello".toFirstUpper() // calls StringExtensions.toFirstUpper("hello")

Method calls in extension syntax often result in more readable code, as they are chained rather than nested. Another benefit of extensions is that you can add methods which are specific to a certain context or layer of your application.

For instance, you might not want to put UI-specific methods and dependencies into your domain model classes. Therefore this functionality is often defined in static methods or methods in utility classes or service layers. That works, but the code is less readable and less object-oriented if you call methods like this. In Java you often see code like this:;

Without tying your entities to the persistenceManager, extension methods allow you to write

There are different ways to make methods available as extensions, which are described in the following sections.

Extensions from the Library

The Xtend library puts a lot of very useful extension methods on existing types from the Java SDK without any further ado.

"hello".toFirstUpper // calls StringExtensions.toFirstUpper(String)[ toUpperCase ] // calls ListExtensions.<T, R>map(List<T> list, Function<? super T, ? extends R> mapFunction)

Have a look at the JavaDoc to learn about the available functionality:

Local Extension Methods

All visible non-static methods of the current class and its super types are automatically available as extensions. For example

class MyClass {
  def doSomething(Object obj) {
    // do something with obj
  def extensionCall(Object obj) {
    obj.doSomething()  // calls this.doSomething(obj)

Local static methods have to be made available through an import like any other static method.

Extension Imports

In Java, you would usually write a helper class with static methods to decorate an existing class with additional behavior. In order to integrate such static helper classes, Xtend allows to put the keyword extension after the static keyword of a static import thus making all imported static functions available as extensions methods.

The following import declaration

import static extension java.util.Collections.singletonList

allows us to use singletonList methods like this:

new MyClass().singletonList() 
// calls Collections.singletonList(new MyClass())

Extension Provider

By adding the extension keyword to a field, a local variable or a parameter declaration, its instance methods become extension methods.

Imagine you want to have some layer specific functionality on a class Person. Let us say you are in a servlet-like class and want to persist a Person using some persistence mechanism. Let us assume Person implements a common interface Entity. You could have the following interface

interface EntityPersistence {
  public save(Entity e);
  public update(Entity e);
  public delete(Entity e);

And if you have obtained an instance of that type (through a factory or dependency injection or what ever) like this:

class MyServlet {
  extension EntityPersistence ep = Factory.get(EntityPersistence)

You are able to save, update and delete any entity like this:

val Person person = ...  // calls = 'Horst'
person.update  // calls ep.update(person)
person.delete  // calls ep.delete(person)

Using the extension modifier on values has a significant advantage over static extension imports: Your code is not bound to the actual implementation of the extension method. You can simply exchange the component that provides the referenced extension with another implementation from outside, by providing a different instance.

Interface Declaration

An interface declaration is very similar to the one in Java. An interface can declare fields, which are by default final static therefore must have an initial value. And of course methods can be declared. They are public by default. Interfaces can extend any number of other interfaces and can declare type parameters.

Here's an example:

interface MyInterface<T> extends OtherInterface {
  val CONSTANT = 42
  def T doStuff(String ... varArg) throws SomeException

Annotation Type Declaration

Annotation types can also be declared. The are introduced by the keyword annotation and declare their values with a concise syntax:

annotation MyAnnotation {
  String[] value
  boolean isTricky = false
  int[] lotteryNumbers = #[ 42, 137 ]

Enum Type Declaration

Enumeration types are declared like this:

enum MyColor {

Nested Type Declarations

Classes, enum, annotation and interface declarations can be nested. Just as in Java nested enums, annotations and interfaces are always static. In Xtend nested classes are also always static. Nested types are public by default and can only be nested within a class, an interface or an annotation declaration.

class MyClass {
  static class NestedClass {}
  annotation NestedAnnotation {}
  enum NestedEnum {}
  interface NestedInterface {}

interface MyInterface {
  static class NestedClass {}
  annotation NestedAnnotation {}
  enum NestedEnum {}
  interface NestedInterface {}

annotation MyAnnotation {
  static class NestedClass {}
  annotation NestedAnnotation {}
  enum NestedEnum {}
  interface NestedInterface {}


In Xtend everything is an expression and has a return type. Statements do not exist. That allows you to compose your code in interesting ways. For example, you can have a try catch expression on the right hand side of an assignment:

val data = try {
  } catch (IOException e) {
    'dummy data'

If fileContentsToString() throws an IOException, it is caught and the string 'dummy data' is assigned to the value data. Expressions can appear as initializers of fields, the body of constructors or methods and as values in annotations. A method body can either be a block expression or a template expression.


A literal denotes a fixed, unchangeable value. Literals for strings, numbers, booleans, null and Java types are supported as well as literals for unmodifiable collection types like lists, sets and maps or literals for arrays.

String Literals

A string literal is of type String. String literals are enclosed in a pair of single quotes or double quotes. Single quotes are more common because the signal-to-noise ration is better, but generally you should use the terminals which are least likely to occur in the string value. Special characters can be quoted with a backslash or defined using unicode notation. Contrary to Java, strings can span multiple lines.

'Hello World !'
"Hello World !"
'Hello "World" !'
"Hello \"World\" !"

  World !"

Character Literals

Character literals use the same notation as String literals. If a single character literal is used in a context where a primitive char or the wrapper type Character is expected, the compiler will treat the literal as such a value or instance.

val char c = 'c'

Number Literals

Xtend supports roughly the same number literals as Java with a few differences. First, there are no signed number literals. If you put a minus operator in front of a number literal it is treated as a unary operator with one argument (the positive number literal). Second, as in Java 7, you can separate digits using _ for better readability of large numbers. An integer literal creates an int, a long (suffix L) or a BigInteger (suffix BI). There are no octal numbers

0xbeef    // hexadecimal
077       // decimal 77 (*NOT* octal)
-1  // an expression consisting of the unary - operator and an integer literal  
0xbeef#L // hexadecimal, mind the '#'
0xbeef_beef_beef_beef_beef#BI // BigInteger

A floating-point literal creates a double (suffix D or none), a float (suffix F) or a BigDecimal (suffix BD). If you use a . you have to specify both, the integral and the fractional part of the mantissa. There are only decimal floating-point literals.

42d     // double
0.42e2  // implicit double
0.42e2f // float
4.2f    // float
0.123_456_789_123_456_789_123_456_789e2000bd // BigDecimal

Boolean Literals

There are two boolean literals, true and false which correspond to their Java counterpart of type boolean.

Null Literal

The null pointer literal null has exactly the same semantics as in Java.

Type Literals

The syntax for type literals is generally the plain name of the type, e.g. the snippet String is equivalent to the Java code String.class. Nested types use the delimiter '.'.

To disambiguate the expression, type literals may also be specified using the keyword typeof.

  • Map.Entry is equivalent to Map.Entry.class
  • typeof(StringBuilder) yields StringBuilder.class

Consequently it is possible to access the members of a type reflectively by using its plain name String.getDeclaredFields.

The keyword typeof is mandatory for references to array types, e.g. typeof(int[]

Previous versions of Xtend (2.4.1 and before) used the dollar as the delimiter character for nested types and enforced the use of typeof for all type literals:

  • typeof(Map$Entry) yields Map.Entry.class

Collection Literals

The methods in CollectionLiterals (src) are automatically imported so it's very easy and convenient to create instances of the various collection types the JDK offers.

val myList = newArrayList('Hello', 'World')
val myMap = newLinkedHashMap('a' -> 1, 'b' -> 2)

In addition xtend supports collection literals to create immutable collections and arrays, depending on the target type. An immutable list can be created like this:

val myList = #['Hello','World']

If the target type is an array as in the following example an array is created instead without any conversion:

val String[] myArray = #['Hello','World']

An immutable set can be created using curly braces instead of the squared brackets:

val mySet = #{'Hello','World'}

An immutable map is created like this:

val myMap = #{'a' -> 1 ,'b' ->2}


Java arrays can be created either using a literal as described in the previous section, or if it should be a new array with a fixed size, one of the methods from ArrayLiterals (src) can be used. The generic newArrayOfSize(int) method works for all reference types, while there is a specific factory method for each primitive type.


val String[] myArray = newArrayOfSize(400)
val int[] intArray = newIntArrayOfSize(400)

Retrieving and setting values of arrays is done through the extension methods get(int) and set(int, T) which are specifically overloaded for arrays and are translated directly to the equivalent native Java code myArray[int].

Also length is available as an extension method and is directly translated to Java's equivalent myArray.length.

Furthermore arrays are automatically converted to lists (java.util.List) when needed. This works similar to how boxing and unboxing between primitives and their respective wrapper types work.


val int[] myArray = #[1,2,3]
val List<Integer> myList = myArray

Type Casts



something as MyClass
42 as Integer


Infix Operators and Operator Overloading

There are a couple of common predefined infix operators. These operators are not limited to operations on certain types. Instead an operator-to-method mapping allows to redefine the operators for any type just by implementing the corresponding method signature. As an example, the runtime library contains a class BigDecimalExtensions (src) that defines operators for BigDecimals. The following code is therefore perfectly valid:

val x = 2.71BD
val y = 3.14BD
val sum = x + y    // calls BigDecimalExtension.operator_plus(x,y)

This is the complete list of all available operators and their corresponding method signatures:

e1 += e2 e1.operator_add(e2)
e1 -= e2 e1.operator_remove(e2)
e1 || e2 e1.operator_or(e2)
e1 && e2 e1.operator_and(e2)
e1 == e2 e1.operator_equals(e2)
e1 != e2 e1.operator_notEquals(e2)
e1 === e2 e1.operator_tripleEquals(e2)
e1 !== e2 e1.operator_tripleNotEquals(e2)
e1 < e2 e1.operator_lessThan(e2)
e1 > e2 e1.operator_greaterThan(e2)
e1 <= e2 e1.operator_lessEqualsThan(e2)
e1 >= e2 e1.operator_greaterEqualsThan(e2)
e1 -> e2 e1.operator_mappedTo(e2)
e1 .. e2 e1.operator_upTo(e2)
e1 >.. e2 e1.operator_greaterThanDoubleDot(e2)
e1 ..< e2 e1.operator_doubleDotLessThan(e2)
e1 => e2 e1.operator_doubleArrow(e2)
e1 << e2 e1.operator_doubleLessThan(e2)
e1 >> e2 e1.operator_doubleGreaterThan(e2)
e1 <<< e2 e1.operator_tripleLessThan(e2)
e1 >>> e2 e1.operator_tripleGreaterThan(e2)
e1 <> e2 e1.operator_diamond(e2)
e1 ?: e2 e1.operator_elvis(e2)
e1 <=> e2 e1.operator_spaceship(e2)
e1 + e2 e1.operator_plus(e2)
e1 - e2 e1.operator_minus(e2)
e1 * e2 e1.operator_multiply(e2)
e1 / e2 e1.operator_divide(e2)
e1 % e2 e1.operator_modulo(e2)
e1 ** e2 e1.operator_power(e2)
! e1 e1.operator_not()
- e1 e1.operator_minus()
+ e1 e1.operator_plus()

The table above also defines the operator precedence in ascending order. The blank lines separate precedence levels. The assignment operators += and -= are right-to-left associative in the same way as the plain assignment operator = is. That is a = b = c is executed as a = (b = c), all other operators are left-to-right associative. Parentheses can be used to adjust the default precedence and associativity.

Short-Circuit Boolean Operators

If the operators ||, &&, and ?: are bound to the library methods BooleanExtensions.operator_and(boolean l, boolean r) (src), BooleanExtensions.operator_or(boolean l, boolean r) (src) resp. <T> T operator_elvis(T first, T second) (src) the operation is inlined and evaluated in short circuit mode. That means that the right hand operand might not be evaluated at all in the following cases:

  1. in the case of || the operand on the right hand side is not evaluated if the left operand evaluates to true.
  2. in the case of && the operand on the right hand side is not evaluated if the left operand evaluates to false.
  3. in the case of ?: the operand on the right hand side is not evaluated if the left operand evaluates to null.

Still you can overload these operators for your types or even override it for booleans, in which case both operands are always evaluated and the defined method is invoked, i.e. no short-circuit execution is happening.

Postfix Operators

The two postfix operators ++ and -- use the following method mapping:

e1++ e1.operator_plusPlus()
e1-- e1.operator_minusMinus()

Defined Operators in The Library

Xtend offers operators for common types from the JDK.

Equality Operators

In Xtend the equals operators (==,!=) are bound to Object.equals. So you can write:

if (name == 'Homer')
	println('Hi Homer')

Java's identity equals semantic is mapped to the tripple-equals operators === and !== in Xtend.

if (someObject === anotherObject)
	println('same objects')

Comparison Operators

In Xtend the usual comparison operators (>,<,>=, and <=) work as expected on the primitive numbers:

if (42 > myNumber) {

In addition these operators are overloaded for all instances of java.lang.Comparable. So you can also write

if (startTime < arrivalTime)
	println("You are too late!")

Arithmetic Operators

The arithmetic operators (+,-,*,/,%, and **) are not only available for the primitive types, but also for other reasonable types such as BigDecimal and BigInteger.

val x = 2.71BD
val y = 3.14BD

Elvis Operator

In addition to null-safe feature calls Xtend supports the elvis operator known from Groovy.

val salutation = person.firstName ?: 'Sir/Madam'

The right hand side of the expression is only evaluated if the left side was null.

With Operator

The with operator is very handy when you want to initialize objects or when you want to use a particular instance a couple of time in subsequent lines of code. It simply passes the left hand side argument to the lambda on the right hand and returns the left hand after that.

Here's an example:

val person = new Person => [
	firstName = 'Homer'
	lastName = 'Simpson'
	address = new Address => [
		street = '742 Evergreen Terrace'
		city = 'SpringField'

Range Operators

There are three different range operators. The most useful ones are ..< and >.. which create exclusive ranges.

// iterate the list forwards
for (i : 0 ..< list.size) {
	val element = list.get(i)

// or backwards
for (i : list.size >.. 0) {
	val element = list.get(i)

In addition there is the inclusive range, which is nice if you know both ends well. In the movies example the range is used to check whether a movie was made in a certain decade:


Please keep in mind that there are other means to iterator lists, too. For example, you may want to use the forEach extension

list.forEach[ element, index |
	.. // if you need access to the current index
  .. // if you just need the element it in reverse order

Pair Operator

Sometimes you want to use a pair of two elements locally without introducing a new structure. In Xtend you can use the ->-operator which returns an instance of Pair<A,B>:

val nameAndAge = 'Homer' -> 42

If you want to surface a such a pair of values on the interface of a method or field, it's generally a better idea to use a data class with a well defined name, instead:

@Data class NameAndAge {
	String name
	int age


Local variables can be assigned using the = operator.

var greeting = 'Hello'
if (isInformal)
  greeting = 'Hi'

Of course, also non-final fields can be set using an assignment:

myObj.myField = 'foo'

Setting Properties

The lack of properties in Java leads to a lot of syntactic noise when working with data objects. As Xtend is designed to integrate with existing Java APIs it respects the Java Beans convention, hence you can call a setter using an assignment:

myObj.myProperty = 'foo' // calls myObj.setMyProperty("foo")

The setter is only used if the field is not accessible from the given context. That is why the @Property annotation would rename the local field to _myProperty.

The return type of an assignment is the type of the right hand side, in case it is a simple assignment. If it is translated to a setter method it yields whatever the setter method returns.

Assignment Operators

Compound assignment operators can be used as a shorthand for the assignment of a binary expression.

var BigDecimal bd = 45bd
bd += 12bd // equivalent to bd = bd + 12bd
bd -= 12bd // equivalent to bd = bd - 12bd
bd /= 12bd // equivalent to bd = bd / 12bd
bd *= 12bd // equivalent to bd = bd * 12bd

Compound assignments work automatically when the infix operator is declared. The following compound assignment operators are supported:

e1 += e2 +
e1 -= e2 -
e1 *= e2 *
e1 /= e2 /
e1 %= e2 %


The block expression allows to have imperative code sequences. It consists of a sequence of expressions. The value of the last expression in the block is the value of the complete block. The type of a block is also the type of the last expression. Empty blocks return null and have the type Object. Variable declarations are only allowed within blocks and cannot be used as a block's last expression.

A block expression is surrounded by curly braces. The expressions in a block can be terminated by an optional semicolon.

Here are two examples:


  var x = greeting;
  if (x.equals("Hello ")) {
    x + "World!" 
  } else {

Variable Declarations

Variable declarations are only allowed within blocks. They are visible from any subsequent expressions in the block.

A variable declaration starting with the keyword val denotes a value, which is essentially a final, unsettable variable. The variable needs to be declared with the keyword var, which stands for 'variable' if it should be allowed to reassign its value.

A typical example for using var is a counter in a loop:

  val max = 100
  var i = 0
  while (i < max) {
    println("Hi there!")
    i = i + 1

Shadowing variables from outer scopes is not allowed, the only exception is the implicit variable it.

Variables declared outside of a lambda expression using the var keyword are not accessible from within the lambda expressions.

A local variable can be marked with the extension keyword to make its methods available as extensions (see extension provider).


The type of the variable itself can either be explicitly declared or it can be inferred from the initializer expression. Here is an example for an explicitly declared type:

var List<String> strings = new ArrayList

In such cases, the type of the right hand expression must conform to the type of the expression on the left side.

Alternatively the type can be inferred from the initializater:

var strings = new ArrayList<String> // -> msg is of type ArrayList<String>

Field Access and Method Invocation

A simple name can refer to a local field, variable or parameter. In addition it can point to a method with zero arguments, since empty parentheses are optional.

Property Access

If there is no field with the given name and also no method with the name and zero parameters accessible, a simple name binds to a corresponding Java-Bean getter method if available:

myObj.myProperty // myObj.getMyProperty()  (.. in case myObj.myProperty is not visible.)

Implicit Variables this and it

Like in Java the current instance of the class is bound to this. This allows for either qualified field access or method invocations like in:


or it is possible to omit the receiver:


You can use the variable name it to get the same behavior for any variable or parameter:

val it = new Person
name = 'Horst' // translates to 'it.setName("Horst");'

Another speciality of the variable it is that it is allowed to be shadowed. This is especially useful when used together with lambda expressions.

As this is bound to the surrounding object in Java, it can be used in finer-grained constructs such as lambda expressions. That is why it.myProperty has higher precedence than this.myProperty.

Static Access

For accessing a static field or method you can use the recommended Java syntax or the more explicit double colon ::. That means, the following epxressions are pairwise equivalent:



Alternatively you could import the method or field using a static import.

Null-Safe Feature Call

Checking for null references can make code very unreadable. In many situations it is ok for an expression to return null if a receiver was null. Xtend supports the safe navigation operator ?. to make such code better readable.

Instead of writing

if (myRef != null) myRef.doStuff()

one can write


Arguments that would be passed to the method are only evaluated if the method will be invoked at all.

For primitive types the default value is returned (e.g. 0 for int). This may not be what you want in some cases, so a warning will be raised by default. You can turn that off in the preferences if you wish.

Constructor Call

Constructor calls have the same syntax as in Java. The only difference is that empty parentheses are optional:

new String() == new String
new ArrayList<BigDecimal>() == new ArrayList<BigDecimal>

If type arguments are omitted, they will be inferred from the current context similar to Java's diamond operator on generic method and constructor calls.

Lambda Expressions

A lambda expression is basically a piece of code, which is wrapped in an object to pass it around. As a Java developer it is best to think of a lambda expression as an anonymous class with a single method, i.e. like in the following Java code :

// Java Code!
final JTextField textField = new JTextField();
textField.addActionListener(new ActionListener() {
  public void actionPerformed(ActionEvent e) {
    textField.setText("Something happened!");

This kind of anonymous classes can be found everywhere in Java code and have always been the poor-man's replacement for lambda expressions in Java.

Xtend not only supports lambda expressions, but offers an extremely dense syntax for it. That is the code above can be written in Xtend like this:

val textField = new JTextField
textField.addActionListener([ ActionEvent e |
  textField.text = "Something happened!"

As you might have guessed, a lambda expression is surrounded by square brackets (inspired from Smalltalk). Also a lambda expression like a method declares parameters. The lambda above has one parameter called e which is of type ActionEvent. You do not have to specify the type explicitly because it can be inferred from the context:

textField.addActionListener([ e |
  textField.text = "The command '" + e.actionCommand + "' happened!"

Also you do not need to speficy the argument names. If you leave them out a single argument will be named it, if the lambda has more arguments the names will be $1,$2,...,$n depending on the numnber of arguments of course. Here's an example with a single argument named it.

  textField.text = "The command '" + actionCommand + "' happened!"

A lambda expression with zero arguments can be written with or without the bar. They are both the same.

val Runnable aBar = [|
  println("Hello I'm executed!")
val Runnable noBar = [
  println("Hello I'm executed!")

When a method call's last parameter is a lambda it can be passed right after the parameter list. For instance if you want to sort some strings by their length, you could write :

Collections.sort(someStrings) [ a, b |
  a.length - b.length

which is just the same as writing

Collections.sort(someStrings, [ a, b |
  a.length - b.length

Since you can leave out empty parentheses for methods which get a lambda as their only argument, you can reduce the code above further down to:

textField.addActionListener [
  textField.text = "Something happened!"

A lambda expression also captures the current scope. Any final local variables and all parameters that are visible at construction time can be referred to from within the lambda body. That is exactly what we did with the variable textField above.

The variable this refers to the outer class. The lambda instance itself is available with the identifier self.

val lineReader = new LineReader(r);
val AbstractIterator<String> lineIterator = [|
	val result = lineReader.readLine 
	if (result==null)
	return result


Lambdas are expressions which produce Function objects. The type of a lambda expression generally depends on the target type, as seen in the previous examples. That is, the lambda expression can coerce to any interface or abstract class which has declared only one abstract method. This allows for using lambda expressions in many existing Java APIs directly.

However, if you write a lambda expression without having any target type expectation, like in the following assignment:

val toUpperCaseFunction = [ String s | s.toUpperCase ] // inferred type is (String)=>String

The type will be one of the inner types found in Functions (src) or Procedures (src). It is a procedure if the return type is void, otherwise it is a function.

Xtend supports a shorthand syntax for function types. Instead of writing Function1<? super String,? extends String> which is what you will find in the generated Java code, you can simply write (String)=>String.


val (String)=>String stringToStringFunction = [ toUpperCase ]
// or
val Function1<? super String,? extends String> same = [ toUpperCase ]
// or
val stringToStringFunction2 = [ String s | s.toUpperCase ] // inferred type is (String)=>String

Checked exceptions that are thrown in the body of a lambda expression but not declared in the implemented method of the target type are thrown using the sneaky-throw technique. Of course you can always catch and handle them.

Anonymous Classes

An anonymous class in Xtend has the very same semantics as in Java (see Java Language Sepcification). Here's an example:

val tabListener = new ActionBar.TabListener() {
  override onTabSelected(ActionBar.Tab tab, FragmentTransaction ft) {
    // show the given tab

  override onTabUnselected(ActionBar.Tab tab, FragmentTransaction ft) {
    // hide the given tab

  override onTabReselected(ActionBar.Tab tab, FragmentTransaction ft) {
    // probably ignore this event

If Expression

An if-expression is used to choose between two different values based on a predicate.

An expression

if (p) e1 else e2

results in either the value e1 or e2 depending on whether the predicate p evaluates to true or false. The else part is optional which is a shorthand for an else branch that returns the default value of the current type, e.g. for reference type this is equivalent to else null. That means

if (foo) x

is a short hand for

if (foo) x else null

The type of an if expression is the common super type of the return types T1 and T2 of the two expression e1 and e2.

While the if expression has the syntax of Java's if statement it behaves more like Java's ternary operator (predicate ? thenPart : elsePart), because it is an expression and returns a value. Consequently, you can use if expressions deeply nested within expressions:

val name = if (firstName != null) firstName + ' ' + lastName else lastName

Switch Expression

The switch expression is very different from Java's switch statement. The use of switch is not limited to certain values but can be used for any object reference. Object.equals(Object) is used to compare the value in the case with the one you are switching over. Given the following example:

switch myString {
  case myString.length > 5 : "a long string."
  case 'some' : "It's some string."
  default : "It's another short string."

the main expression myString is evaluated first and then compared to each case sequentially. If the case expression is of type boolean, the case matches if the expression evaluates to true. If it is not of type boolean it is compared to the value of the main expression using Object.equals(Object).

If a case is a match, that is it evaluates to true or the result equals the one we are switching over, the case expression after the colon is evaluated and is the result of the whole switch expression.

The main expression can also be a computed value instead of a field or variable. If you want to reuse that value in the body of the switch expression, you can create a local value for that by using the following notation which is similar to the syntax in for loops.

switch myString : someComputation() {

Type guards

Instead of or in addition to the case guard you can specify a type guard. The case only matches if the switch value conforms to this type. A case with both a type guard and a predicate only matches if both conditions match. If the switch value is a field, parameter or variable, it is automatically casted to the given type within the predicate and the case body.

def length(Object x) {
  switch x {
    String case x.length > 0 : x.length // length is defined for String 
    List<?> : x.size    // size is defined for List
    default : -1

Switches with type guards are a safe and much more readable alternative to instance of / casting cascades you might know from Java.

Fall Through

You can have multiple type guards and cases separated with a comma, to have all of them share the same then part.

def isMale(String salutation) {
  switch salutation {
    case "Mr.", 
    case "Sir" : true
    default : false

For Loop

The for loop

for (T1 variable : arrayOrIterable) expression

is used to execute a certain expression for each element of an array or an instance of Iterable. The local variable is final, hence cannot be updated.

The type of a for loop is void. The type of the local variable can be inferred from the iterable or array that is processed.

for (String s : myStrings) {

for (s : myStrings)

Basic For Loop

The traditional for loop

for (<init-expression> ;  <predicate> ; <update-expression>) body-expression

is very similar to the one known from Java, or even C. When executed, it first executes the init-expression, where local variables can be declared. Next the predicate is executed and if it evaluates to true, the body-expression is executed. On any subsequent iterations the update-expressio is executed instead of the init-expression. This happens until the predicate returns false.

The type of a for loop is void.


While Loop

A while loop

while (predicate) expression

is used to execute a certain expression unless the predicate is evaluated to false. The type of a while loop is void.

while (true) {

while ((i=i+1) < max) 

Do-While Loop

A do-while loop

do expression while (predicate)

is used to execute a certain expression until the predicate is evaluated to false. The difference to the while loop is that the execution starts by executing the block once before evaluating the predicate for the first time. The type of a do-while loop is void.

do {
} while (true)

do doSideEffect("foo") while ((i=i+1)<max)

Return Expression

A method or lambda expression automatically returns the value of its body expression. If it is a block expression this is the value of the last expression in it. However, sometimes you want to return early or make it explicit.

The syntax is just like in Java: [ e | 
  if (e==null) 
    return "NULL"

Throwing Exceptions

Throwing Throwables up the call stack has the same semantics and syntax as in Java.

  if (myList.isEmpty)
    throw new IllegalArgumentException("the list must not be empty")

Try, Catch, Finally

The try-catch-finally expression is used to handle exceptional situations. Checked exceptions are treated like runtime exceptions and only optionally validated. You can but do not have to catch them as they will be silently thrown (see the section on declared exceptions).

try {
  throw new RuntimeException()
} catch (NullPointerException e) {
  // handle e
} finally {
  // do stuff

For try-catch it is again beneficial that it is an expression, because you can write code like the following and do not have to rely on non-final variables:

val name = try {
  } catch (IOException e) {


The synchonized expression does the same as it does in Java (see Java Language Specification). The only difference is that in Xtend it is an expression and can therefore be used at more places.

synchronized(lock) {

val name = synchronized(lock) { 

Template Expressions

Templates allow for readable string concatenation. Templates are surrounded by triple single quotes ('''). A template expression can span multiple lines and expressions can be nested which are evaluated and their toString() representation is automatically inserted at that position.

The terminals for interpolated expression are so called guillemets «expression». They read nicely and are not often used in text so you seldom need to escape them. These escaping conflicts are the reason why template languages often use longer character sequences like e.g. <%= expression %> in JSP, for the price of worse readability. The downside with the guillemets in Xtend is that you will have to have a consistent encoding. Always use UTF-8 and you are good.

If you use the Eclipse plug-in the guillemets will be inserted on content assist within a template. They are additionally bound to CTRL+SHIFT+< and CTRL+SHIFT+ for « and » respectively. On a Mac they are also available with alt+q («) and alt+Q (»).

Let us have a look at an example of how a typical method with a template expressions looks like:

def someHTML(String content) '''

As you can see, template expressions can be used as the body of a method. If an interpolation expression evaluates to null an empty string is added.

Template expressions can occur everywhere. Here is an example showing it in conjunction with the powerful switch expression:

def toText(Node n) {
  switch n {
    Contents : n.text

    A : '''<a href="«n.href»">«n.applyContents»</a>'''

    default : '''

Conditions in Templates

There is a special IF to be used within templates:

def someHTML(Paragraph p) '''
      «IF p.headLine != null»

Loops in Templates

Also a FOR expression is available:

def someHTML(List<Paragraph> paragraphs) '''
      «FOR p : paragraphs»
        «IF p.headLine != null»

The for expression optionally allows to specify what to prepend (BEFORE), put in-between (SEPARATOR), and what to put at the end (AFTER) of all iterations. BEFORE and AFTER are only executed if there is at least one iteration. (SEPARATOR) is only added between iterations. It is executed if there are at least two iterations.

Here is an example:

def someHTML(List<Paragraph> paragraphs) '''
      «FOR p : paragraphs BEFORE '<div>' SEPARATOR '</div><div>' AFTER '</div>'»
        «IF p.headLine != null»


The template expression is of type CharSequence. It is automatically converted to String if that is the expected target type.

White Space Handling

One of the key features of templates is the smart handling of white space in the template output. The white space is not written into the output data structure as is but preprocessed. This allows for readable templates as well as nicely formatted output. The following three rules are applied when the template is evaluated:

  1. Indentation in the template that is relative to a control structure will not be propagated to the output string. A control structure is a FOR-loop or a condition (IF) as well as the opening and closing marks of the template string itself. The indentation is considered to be relative to such a control structure if the previous line ends with a control structure followed by optional white space. The amount of indentation white space is not taken into account but the delta to the other lines.
  2. Lines that do not contain any static text which is not white space but do contain control structures or invocations of other templates which evaluate to an empty string, will not appear in the output.
  3. Any newlines in appended strings (no matter they are created with template expressions or not) will be prepended with the current indentation when inserted.

Although this algorithm sounds a bit complicated at first it behaves very intuitively. In addition the syntax coloring in Eclipse communicates this behavior.

Syntax Coloring For Templates In Eclipse

The behavior is best described with a set of examples. The following table assumes a data structure of nested nodes.

class Template {
  def print(Node n) '''
    node «» {}

node NodeName {}

The indentation before node «» will be skipped as it is relative to the opening mark of the template string and thereby not considered to be relevant for the output but only for the readability of the template itself.

class Template {
  def print(Node n) '''
    node «» {
      «IF hasChildren»

node Parent{
  node FirstChild {
  node SecondChild {
    node Leaf {

As in the previous example, there is no indentation on the root level for the same reason. The first nesting level has only one indentation level in the output. This is derived from the indentation of the IF hasChildren condition in the template which is nested in the node. The additional nesting of the recursive invocation[print] is not visible in the output as it is relative the the surrounding control structure. The line with IF and ENDIF contain only control structures thus they are skipped in the output. Note the additional indentation of the node Leaf which happens due to the first rule: Indentation is propagated to called templates.

Active Annotations

Active Annotations allow developers to participate in the translation process of Xtend source code to Java code via library. That's useful in cases where Java requires to write a lot of boilerplate manually. For instance, many of the good old design patterns fall into this category. With Active Annotations you no longer need to remember how the Visitor or the Observer pattern should be implemented. In Xtend you can implement the expansion of such patterns in a library and let the compiler do the heavy lifting for you.

An Active Annotation is just an annotation declared either in Java or Xtend, which is itself annotated with @Active (src). @Active takes a type literal as a parameter pointing to the processor.

The IDE plugin comes with an example project, which you can easily materialize into your workspace. To do so use the new project wizard and in the category Xtend Examples choose the active annotation example. The examples contain three different annotations which we will use for further explanation.

For instance, @Extract is an annotation which extracts an interface for a class. The annotation declaration looks like this:

annotation Extract {}

Annotation Processor

A processor class must implement one or more of the lifecycle call-back interfaces provided by the compiler. This interfaces are:

  • RegisterGlobalsParticipant (src) The first call back. Only called to register type names when a global symbol table (i.e. index) is created. See
  • TransformationParticipant (src) This callback is often the most useful, as it allows to alter the translated Java structure by e.g. adding, removing or altering members See
  • ValidationParticipant (src) Although you can already do validation during transformation, you are only during this callback allowed to fully resolve any types. See
  • CodeGenerationParticipant (src) If you want to generate some additional text, e.g. XML, this hook is for you. See

There are base classes that implment all callback interfaces. You should subclass one of those depending on your annotation target:

If you want to annotate other elements such as parameters or constructors, you should have a look at the bases classes and adapt their implementation (basically the type parameter) accordingly. It is also possible to have a very generic processor by using Declaration (src), the super type of all declared elements.

Phase 1: Register Globals

The first phase in the lifecycle of the compiler is about indexing the types as globally available symbols. By implementing a RegisterGlobalsParticipant (src) you have the chance to create and register new Java types during this phase. It's important to do this in a first phase so later on the compiler can find and access these types.

For example the ExtractProcessor adds one interface per annotated class:

class ExtractProcessor extends AbstractClassProcessor {
  override doRegisterGlobals(ClassDeclaration annotatedClass, RegisterGlobalsContext context) {

  def getInterfaceName(ClassDeclaration annotatedClass) {

The RegisterGlobalsContext (src) provides all the services that are available during this compilation step. It is passed into the method doRegisterGlobals() along with a read-only representation of the annotated source elements. The AbstractClassProcessor in this example is invoked for all classes that are annotated with @Extract.

The compiler calls RegisterGlobalsParticipant (src) once per compilation unit and provides access to all elements which are annotated with the active annotation this processor is registered for. Therefore the ExtractProcessor is invoked with a list of all classes that are defined in the same Xtend file for all the files that are being compiled.

Phase 2: Transformation

In the second phase developers can modify the compiled Java classes and Java code. Annotation processors that implement TransformationParticipant (src) participate in this compile step. Similar to the RegisterGlobalsParticipant (src) interface the compiler provides two arguments: The list of annotated translated and now mutable Java elements and a TransformationContext (src). The context provides services that are specific for this second step.

A transformation participant can access and modify mutable Java elements. These are an in-memory representation of the generated Java code. They are usually very similar to the source elements, but can be modified and new methods, fields or constructors can be added. It is not possible to create new types during the transformation step. Also note, that other annotation processors might already have altered the model.

The ExtractProcessor implements the method doTransform like this:

class ExtractProcessor extends AbstractClassProcessor {
  override doRegisterGlobals(ClassDeclaration annotatedClass, RegisterGlobalsContext context) {

  def getInterfaceName(ClassDeclaration annotatedClass) {
  override doTransform(MutableClassDeclaration annotatedClass, extension TransformationContext context) {
    val interfaceType = findInterface(annotatedClass.interfaceName)
    // add the interface to the list of implemented interfaces
    annotatedClass.implementedInterfaces = annotatedClass.implementedInterfaces + #[interfaceType.newTypeReference]
    // add the public methods to the interface
    for (method : annotatedClass.declaredMethods) {
      if (method.visibility == Visibility.PUBLIC) {
        interfaceType.addMethod(method.simpleName) [
          docComment = method.docComment
          returnType = method.returnType
          for (p : method.parameters) {
            addParameter(p.simpleName, p.type)
          exceptions = method.exceptions

In the first line, findInterface retrieves the interface which was registered during the registration of global symbols in the first phase: The method is defined in TransformationContext (src) which is used as an extension provider.

Next up the newly created interface is added to the existing list of implemented interfaces.

annotatedClass.implementedInterfaces = annotatedClass.implementedInterfaces + #[interfaceType.newTypeReference]

The code calls setImplementedInterfaces(Iterable<TypeReference>) on the annotated class. The right hand side of the assignment is a concatenation of the existing implemented interfaces and a type reference pointing to the freshly created interface.

A TypeReference (src) can be created using one of the various methods from TypeReferenceProvider (src) which is a super type of TransformationContext (src). These utilities are available as extensions, too.

Phase 3: Validation

The third lifecycle allows to participate in validation. You can already do validation during transformation and even during registerGlobals, but it is only now that you can fully resolve everything, including inferred type references.

Phase 4: Code Generation

The last phase in the lifecycle of the compiler lets you participate in writing and updating the files. In the IDE this phase is only executed on save , while the previous two get executed after minor edits in the editor as well. In order to participate your processor needs to implement CodeGenerationParticipant (src). The extract interface example doesn't make use of this hook, but another example for internationalization which is also included, generates a *.properties file, like this:

class ExternalizedProcessor extends AbstractClassProcessor {
  override doGenerateCode(List<? extends ClassDeclaration> annotatedSourceElements, extension CodeGenerationContext context) {
    for (clazz : annotatedSourceElements) {
      val filePath = clazz.compilationUnit.filePath
      val file = filePath.targetFolder.append(clazz.qualifiedName.replace('.', '/') + ".properties")
      file.contents = '''
        «FOR field : clazz.declaredFields»
          «field.simpleName» = «field.initializerAsString»


The CodeGenerationContext (src) provides all the services that are available during this phase. Have a look at the Java doc for more details.

On Expressions and Statements

Most of the generated Java code is represented in the form of in-memory elements. Basically all the structural elements are represented as a dedicated Element (src). If you want to generate the body of a method or the initializer of a field, you have two options.

Generating Blackbox Java Code

The first option is to assign a compilation strategy and take care of the Java code by yourself. As an example the body of a setter method of an observable instance is implemented by the following code snippet:

observableType.addMethod('set' + fieldName.toFirstUpper) [
  addParameter(fieldName, fieldType)
  body = '''
    «fieldType» _oldValue = this.«fieldName»;
    this.«fieldName» = «fieldName»;
    _propertyChangeSupport.firePropertyChange("«fieldName»", _oldValue, «fieldName»);

A template expression is used to implement the body. Although this code is execute during transform, the actual concatenation only happens during code generation. It's a special form of a string concatenation, that will automatically add imports when concatenating a TypeReference, java.lang.Class or a TypeDeclaration. It takes existing imports into account and adds new imports on the fly if necessary.

Assigning Expressions

A second alternative is to put expressions from the Xtend source into the context of a generated Java element. This allows to directly use the code that was written in the source file. An annotation @Lazy which turns fields into lazily initialized properties, may be used like this:

class MyClass {
  @Lazy String myField = expensiveComputation()

The processor for this active annotation could infer a synthetic initializer method and add a getter-method, which calls the initializer if the field is still null. Therefore, the initialization expression of the field has to become the method body of the synthesized initializer method. The following code performs this transformation:

override doTransform(MutableFieldDeclaration field, extension TransformationContext context) {

  // add synthetic init-method
  field.declaringType.addMethod('_init' + field.simpleName) [
    visibility = Visibility.PRIVATE
    returnType = field.type
    // reassign the initializer expression to be the init method's body
    // this automatically removes the expression as the field's initializer
    body = field.initializer

  // add a getter method which lazily initializes the field
  field.declaringType.addMethod('get' + field.simpleName.toFirstUpper) [
    returnType = field.type
    body = ['''
      if («field.simpleName»==null)
        «field.simpleName» = _initÂ«field.simpleName»();
      return «field.simpleName»;

Custom Compiler Checks

The previous example requires each annotated field to have an initializer. Otherwise it would not be possible to use lazy initialization to assign its value. Also a simple check for a null reference could cause trouble with primitive values. A validation for that case would be sensible, too. In order to guide the user dedicated compilation errors should be raised if these constrains are violated.

The TransformationContext (src) inherits methods for exactly that purpose from the ProblemSupport (src) service.

Since the context is declared as an extension provider, those methods can be used as extensions and it allows to implement the constraint check accordingly:

override doTransform(MutableFieldDeclaration field, extension TransformationContext context) {
  if (field.type.primitive)
    field.addError("Fields with primitives are not supported by @Lazy")
  if (field.initializer == null)
    field.addError("A lazy field must have an initializer.")

This ensures that the user is notified about invalid applications of the active annotation @Lazy.

Class Path Setup and Testing

An active annotation can not be used in the same project it is declared in, but has to reside on an upstream project. Alternatively it can be compiled and deployed in a jar. The annotation and the processor itself only rely on the interfaces defined in org.eclipse.xtend.lib.macro which is part of Xtend's small standard library.

Also note that the macro library as well as the processors are strictly speaking compile-time only dependencies. So if it matters, like e.g. on Android devices, you don't need to ship them at runtime.

When used in an IDE the compiled annotation processor is loaded and executed on the fly within the IDE process.

Therefore, careful testing and debugging of the processor is essential. It is best done in a unit test. Such a test needs the whole Xtend compiler on the class path, which you can obtain by means of an OSGi bundle dependency or via Maven. The maven dependency is


and the equivalent OSGI bundle is org.eclipse.xtend.core.


The XtendCompilerTester is a convenient helper class for testing the processing and the compilation. It allows to test active annotation processors by either comparing the generated Java source using a String comparison or by inspecting the produced Java elements. In addition you can even compile the generated Java source to a Java class and create and test instances of it reflectively.

The example project contains a couple of test cases:

class LazyTest {
  extension XtendCompilerTester compilerTester = XtendCompilerTester.newXtendCompilerTester(Lazy)

  @Test def void testLazy() {
      import lazy.Lazy
      class Person {
        @Lazy String name = 'foo'
      import lazy.Lazy;

      public class Person {
        private String name;
        private String _initname() {
          return "foo";
        public String getName() {
          if (name==null)
            name = _initname();
          return name;

This is a basic string comparison. It is a good way to start the development of a new annotation processor. Later on assertions against the produced elements and syntax tree (AST) may be a better choice since these are not so fragile against changes in the formatting. The @Extract-example uses this technique:

@Test def void testExtractAnnotation() {
    class MyClass {
      override String doStuff(String myParam) throws IllegalArgumentException {
        return myParam
  '''.compile [
    // declare the transformation context as a local extensions
    val extension ctx = transformationContext
    // look up the interface and the class
    val interf = findInterface('MyClassInterface')
    val clazz = findClass('MyClass')
    // do assertions
    assertEquals(interf, clazz.implementedInterfaces.head.type)
    interf.declaredMethods.head => [
      assertEquals('doStuff', simpleName)
      assertEquals(string, returnType)
      assertEquals(IllegalArgumentException.newTypeReference, exceptions.head)

Wrap Up

Active Annotations are a powerful and unique concept that allows to solve a large class of problems that previously had to be solved in cumbersome ways. IDE wizards, many code generators or manually writing boilerplate code are no longer state of the art. Active annotations basically is a means of code generation, but its simple integration with existing projects and the fast development turnarounds diminish the typical downsides of code generation.

Existing Active Annotations

Xtend comes with ready-to-use active annotations for common code patterns. They reside in the org.eclipse.xtend.lib.annotations plug-in/jar which must be on the class path of the project containing the Xtend files.


If you want to add getter and or setter methods for your fields @Accessors (src) is your friend. Here's a basic example.

@Accessors String name

will compile to the Java code

private String name;

public String getName() {

public void setName(final String name) { = name;

So by default a public getter and a public setter method is created. The @Accessors can be configured to tell that you only want one or the other and to change the visibility. this is done by means of AccessorType (src) You can also use the annotation on class level to do the same for all fields.

Here is a more complex example, that shows how it works:

@Accessors class Person {
  String name
  String firstName
  @Accessors(NONE) String internalField

will compile to the Java code

@Accessors public class Person {
  private String name
  private String firstName
  @Accessors(PUBLIC_GETTER, PROTECTED_SETTER) private int age
  @Accessors(NONE) private String internalField
  public String getName() {
  public void setName(final String name) { = name;
  public String getFirstName() {
    return this.firstName;
  public void setFirstName(final String firstName) {
    this.firstName = firstName;
  public int getAge() {
    return this.age;
  protected void setAge(final int age) {
    this.age = age;


The annotation @Data (src), will turn an annotated class into a value object class. A class annotated with @Data is processed according to the following rules:

  • all fields are final,
  • getter methods will be generated (if they do not yet exist),
  • a constructor with parameters for all non-initialized fields will be generated (if it does not exist),
  • equals(Object) / hashCode() methods will be generated (if they do not exist),
  • a toString() method will be generated (if it does not exist).


@Data class Person {
  String firstName
  String lastName
  def static void main(String[] args) {
    val p = new Person(args.get(0), args.get(1))
    println(p.getFirstName() + ' ' + p.lastName)


The @Delegate (src) annotation automatically generated delegate methods for all interfaces shared between the delegate and the currently implemented class. You can optionally restrict it to explicitly stated interfaces.

Let's start with a basic example:

class MyClass implements SomeInterface

  // generates all methods of List and delegates to this field
  @Delegate SomeSubTypeOfSumInterface myDelegate

It is not only possible to delegate to fields, but also to methods so you for instance could lazily create the delegate object or use a different one each time. If you use a method you can also declare additional parameters, that will tell you about the method that should be invoked.

Here's another example:

class MyClass implements SomeInterface {

  SomeInterface myDelegate;

  @Delegate def List<? extends String> provideDelegate(String methodName, Class[] paramTypes, Object[] actualArguments) {
     if (!canHandle(methodName,paramTypes,actualArguments) {
        throw new UnsupportedOperationException("The method "+methodName+" is not supported.");
     return myDelegate

@Xtendlang on Twitter