We’re hiring a lot, and that means a lot of interviews. Being keen to help find our future colleagues, a bunch of us are training to run the technical selection process, which includes a Java coding test.
As a trainee interviewer for Java developers myself, I need to get intimate with the test’s codebase. What better way to do so than to port it to an interesting new language?
Xtend?
Head to the Xtend website for juicy details, but in summary, Xtend:
- resembles Java
- compiles to Java source
- is designed to co-exist with Java code
- requires just a thin runtime library
- focuses on handy syntactic sugar rather than ground-breaking language features
- is written & used by people involved in an Eclipse-based framework for building DSLs and tooling around those DSLs (Xtext).
I won’t share the resulting Xtend coding test implementation with you: it‘s close enough to the original Java version that it would ruin the surprise for candidates. However, I can give you my impressions of Xtend after a few hours of dabbling.
The Language
The language delivers on its promise: it is very approachable from the perspective of a Java developer and is effective at making code more concise.
Extension Methods
This is my favourite feature. Extension methods can be called as though the first argument were the receiver type, regardless of where the method is declared. So for example, Xtend’s own library (which is written in Java) provides the following extension method for Iterable:
[cc lang=”java” escaped=”true” line_numbers=”0″]public class IterableExtensions {
//…
/**
* Determines if the given iterable is null or contains no elements.
* @param iterable the to-be-queried iterable. May be null.
* @return {@code true} if the iterable is null or contains no elements
*/
public static final boolean isNullOrEmpty(Iterable<?> iterable) {
return iterable == null || isEmpty(iterable);
}
//…
}[/cc]
That method can can be consumed in Xtend as follows:
[cc lang=”java” escaped=”true” line_numbers=”0″]class Zombie implements Dismemberable {
def feedOn(Collection<Brain> brains) {
if (!brains.nullOrEmpty) {
brains.forEach(brain | this.eat(brain))
}
}
}[/cc]
In the code above, brains.nullOrEmpty invokes IterableExtensions.isNullOrEmpty(), and brains.forEach invokes another such extension method that takes a closure as an additional parameter.
Xtend’s runtime library provides a bunch of these utility extensions, and you can of course implement your own.
Templating
Templating using Rich Strings is presented as one of the language’s main features. I haven’t really made use of it yet; this video shows how it can be used for code generation.
Misc observations
Aside from that, here’s what I considered noteworthy after a couple of hours:
- No support for declaring interfaces.
- No support for declaring static methods or fields.
- No support for declaring constructors and no support for field initialisers.
- No var args, no nested classes, no anonymous classes?
The language very much intends for you to use interfaces, but expects them to be written directly in Java.
Not a bad thing, but it does mean you’ll have to find another language to provide a main method to drive your Xtend Hello World. 🙂 Support for both static methods and fields is planned for the next version of Xtend.
This encourages the use of dependency injection everywhere (Guice is recommended, and is used within Xtend’s runtime library, so is within immediate reach for any Xtend project (as are Google Collections)). Nonetheless, support for both constructors and field initialisers is planned for the next version of Xtend.
Those language features are not mentioned in the docs, and I could not guess a valid syntax. I assume they are not available, but I could be wrong.
The IDE Experience
Overall, for a young language, the Eclipse tooling is excellent. This is unsurprising given Xtend’s background, and is one of the language’s big selling points. Nonetheless, there are a few gotchas:
- Creating a new, working Xtend project in Eclipse is not entirely trivial.
- Stacktraces, the debugger and code navigation point to generated Java code.
- Quickfixes don’t work well, and some are missing (e.g. no quickfix for generating unimplemented methods).
In particular, Xtend requires a few mandatory libraries which are not included by default when adding the Xtend nature to a Java project. Until you take steps to include those libraries, Xtend classes will fail to compile with errors like: “Mandatory library bundle ‘org.eclipse.xtext.xbase.lib’ not found on the classpath”. The required libraries are not yet in any public Maven repos, but are included in Eclipse plugins. So, the best way I could find to quickly get started is to create an Eclipse PDE project and add the appropriate libraries as plugin dependencies. I found Max Rohde’s Xtend tutorial very useful here.
While debugging or just browsing your codebase, it’s all too easy to end up in generated Java code. You then have to manually find the corresponding piece of Xtend code. Fortunately, Eclipse does mark the generated code as derived, preventing you from accidentally editing it.
There is no IDEA tooling that I know of for Xtend. Use Eclipse.
Conclusion
I won’t try to claim you should stop learning your favourite new language and switch to Xtend: it’s relatively frugal on the feature front, and therefore perhaps less exciting than others.
That said, it’s quick to pick up. You could get the hang of it during a short break away from that beefy Scala book. Porting a couple of simple classes was enough for me to realise that the syntactic sugar is simple, yet very neat. I predict I’ll soon regret not having it at hand when writing plain Java.
So, if you’re after a gradual improvement on top of Java, or are keen to write more succinct code with minimal impact on the runtime requirements of an existing Java app, give it a try!
By the way, check out my Grovember Mo’. Donate if I look ridiculous! 🙂