Xtend 2.4 Adds Active Annotations, Android Support and More

Today, the Eclipse Foundation announced the release of Xtend 2.4, a statically-typed Java-esque programming language that compiles down to Java and runs on the JVM (and JVM like systems such as Android).

Unlike other JVM-based compiled languages such as Scala and Kotlin, Xtend is translated to Java source and then compiled with the standard Java compiler, so there are no backward compatibility issues with the resulting output.

Xtend differs from interpreted languages such as Groovy and JRuby/Jython in that the language is statically typed but has type inference to support simple coding, which means refactorings and type-specific completions are possible in the IDE.

InfoQ covered the 1.0 release last year, but a lot has changed in the interim. The new features in 2.4 include active annotations, collection literals, Android support and improved refactoring and content assist in the tooling.

InfoQ caught up with Sven Efftinge, project lead of Xtend, to find out more about the release, and started by asking:

InfoQ: One of the new features in Xtend 2.4 is the addition of active annotations. Can you explain what they are, and how they cut down on boilerplate code?

Sven Efftinge: You basically declare an annotation and tell the compiler how annotated elements should be translated to Java code. Typical use cases are generating getters and setters, observers or other common design patterns such as visitors – but you can do much more with them. We've focussed on making it super easy to develop and deploy active annotations.

As an example, consider the JavaBean pattern for properties. This requires the creation of a get/set method pair, which contributes to what some refer to as 'Java code bloat'. In Xtend, you just need to declare that your field should be a property and Xtend does the rest:

@Property String name

This is translated into the following Java code:

private String name;
public String getName() {
  return this.name;
}
public void setName(String name) {
  this.name = name;
}

There are other annotations, such as @Data, which generates hashCode() and equals() for you automatically, and @Observable which can be applied to a data class to get automatic support for property change listeners, as described in the release notes.

The coolest thing is that the IDE and the compiler are aware of your changes. So all the typing, linking as well as stuff like navigation and content assist just work as expected, as changes are applied on the fly.

It's how code generation should be.

InfoQ: Another new feature is that of literal collections. What is the syntax for using literal arrays, sets and maps? Can these be nested?

Sven Efftinge: The syntax is a hash followed by either curly braces or squared brackets. For lists you use:

val myList = #[1,2,3,4]

And for sets it is:

val mySet = #{1,2,3}

Maps are created using the tuple operator:

val mySet = #{1->"one",2->"two" }

The list literal can also be used as an array literal when the expected type is an array, as in:

val int[] myArray = #[1,2,3,4]

And yes, they can be nested as they are just expressions.

InfoQ: Are literal collection types mutable or immutable? How can you seed a mutable collection with a literal one?

Sven Efftinge: Yes, they are immutable. If you want a mutable one you use one of the factory methods:

val myArrayList = newArrayList(1,2,3,4)

Of course you can also construct them with existing immutable lists.

InfoQ: Speaking of literals, what are extension providers and how do they compare to extension methods?

Sven Efftinge: Extension providers are objects on the scope of your program which provide extension methods. This is best explained by example. Consider you have a Data Access Object (DAO) class, with methods like save(Entity).

In Java you have to write:

myDao.save(myEntity)

In Xtend you could make the DAO object an extension provider which lets you use its methods as member methods on their first argument type. So instead you can write:

myEntity.save()

This is an important enhancement over C# extension methods (where only static methods can be used as extensions). Extension providers let you exchange the actual implementation easily.

InfoQ: JDK 8 has the concept of converting Lambdas into Single Access Method (SAM) types. Is this possible on Java 6 or Java 7 with Xtend today?

Sven Efftinge: In JDK8 lambdas can only be converted to so called functional interfaces. This is done in Xtend in the same way. The new addition is that you can now also use abstract classes with a SAM type. They are frequently used by frameworks such as "Functional Java".

With Xtend, you don't need to wait for JDK8 to be able to do this; you can do it in Java 6 or Java 7 today. In fact, Xtend is compatible with Java 5.

InfoQ: Speaking of backward compatibility, what's the story with Xtend? Can programs compiled against Xtend 1.0 still be used against Xtend 2.4 today?

Sven Efftinge: They are binary compatible, so programs compiled against Xtend 1.0 will work with Xtend 2.4 without any recompilation or changes needed.

At the source level there are no breaking changes, although we have improved the compiler's error reporting which can highlight semantic errors where before the compiler wouldn't have warned you.

We take compatibility seriously, both at the compiled level and at the source level.

InfoQ: Being able to compile Xtend projects and install onto Android seems like a great win for the framework. Given that compiling Android applications with Scala or Kotlin add many megabytes to the package, what is the average size increase of compiling an Android application with Xtend versus coding directly in Java?

Sven Efftinge: Xtend compiles to Java source code which in turn is compiled to Java byte code. This ensures that the created byte code works nicely with Android. Also Xtend doesn't have its own fat library. There are only a couple of classes adding extension methods to existing JDK types (<40K) and Google Guava, which is 1.3M.

You can write pretty efficient Android apps with Xtend.

InfoQ: One of the success criteria for a language is that it has excellent IDE support. How is Xtend's support in Eclipse evolving?

Sven Efftinge: The IDE has many new features like formatter, new quick fixes, new refactorings and much improved content assist.

Also the compiler performance has been improved a lot, too. We have a strong focus on enabling a good flow when working with Xtend and the IDE.

Unlike other JVM based languages, Xtend works with rather than against the JDT. You don't need to replace the JDT or enable weaving to use it. In addition, you can use any version of the Java compiler to be able to compile the project; you're not limited to just the version installed as the plug-in.

Xtend 2.4 is available for release notes for 2.4. For more information on Xtend, see the Xtend home page.