News

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Latest Xtext Release Integrates with JVM

Posted by Jean-Jacques Dubray on Nov 03, 2011

Sections: Architecture & Design,; Development
Topics: JVM ,; Virtual Machines ,; Runtimes ,; Java ,; Domain Specific Languages ,; Languages ,; Programming

Xtext 2.1 was released this week by the Eclipse Foundation. It comes with many new features and a major innovation: the support for creating domain specific languages targeting the Java virtual machine.

You can now directly embed the expression language, Xbase, in your own language:

For most cases it is enough to specify how your language concepts relate to the JVM typesystem. The framework then derives all other services such as scoping or even the code generator from this mapping automatically.

Xbase itself has been enhanced:

with the introduction of a second implicit variable named it. As opposed to the existing this, you can declare and override it, e.g. as a function parameter.
If the last argument of a function call is a closure it can now be specified after the feature call. This way you can provide extension libraries that look like new statements.

Sven Efftinge provided a 5 step tutorial to create a JVM language. Sven shows how to add support for expressions and cross links to Java types in the domain language that has been used as a support Xtext since its inception. Sven shows how:

[your language can support] all kinds of advanced features such as Java generics and full expressions even including closures. Don't panic you'll not have to implement these concepts on your own but will reuse a lot of helpful infrastructure to build the language.

The fundamentamental difference between Xtext and other Model Driven Engineering approach resides in the fact that:

We need to map the domain specific concepts to some other language in order to tell Xtext how it is executed. Usually you define a code generator or an interpreter for that matter, but languages using Xbase can omit this step and make use of the IJvmModelInferrer (src).

The idea is that you translate your language concepts to any number of Java types (JvmDeclaredType (src) ). Such a type can be a Java class, Java interface, Java annotation type or a Java enum and may contain any valid members. In the end you as a language developer are responsible to create a correct model according to the Java language.

By mapping your language concepts to Java elements, you implicitly tell Xtext in what kind of scopes the various expressions live and what return types are expected from them. Xtext 2.1 also comes with a code generator which can translate that Java model into readable Java code, including the expressions.

Other important new features include:

Rename refactoring enables now to reliably rename elements and references across language and resource boundaries
Improved intellisense capabilities
Improved builder performance
A new experimental extension to the testing framework allows JUnit4-Tests to be parameterized with DSL files and "Expectations" can be configured right within the DSL files using comments

Xtend also features a number of improvements:

A second implicit variable named it has been introduced, just like in Xbase. You can declare and override it, e.g. as a function parameter. Use it to omit a single parameter in closures or as the default variable in create extensions
Xtend now supports procedures. If a closure does not return a value you don't have to specify it.
If the last argument of a function call is a closure it can now be specified after the feature call.
Members of Xtend classes can now be defined as 'private', 'protected' or 'public'. The default visibility stays 'public' for classes and methods and 'private' for fields.
The name of an field can be omitted, if the field is injected as an extension
The type inference for generic types and arrays has been improved, such that you can skip explicit type declarations in even more cases
Import statements in Xtend files can now be organized as in JDT
The code generator translates comments from Xtend artifacts to JavaDoc in the generated Java code.
Rename refactoring has been revised to integrate seamlessly with JDT

Xtext has been evolving at a rapid pace with very exciting new features, much more rapidly maybe than its community can follow. Are you using Xtext? for what kind of applications? if yes, where would you like to see Xtext going?