The Xtext team is happy to announce the release 2.11. The update is available on the release repository. Eclipse independent libraries are published to Maven Central. We encourage users to upgrade now and enjoy an even better experience with the Xtext framework.
Much work has been done for the new release. A large portion of it has been invested into the restructuring activities. Finally, these activities are finished and Xtext is splitted into several repositories with clear dependencies. We hope to have now a clearer structure, faster builds and better separation of core code from IDE or tool specific code.
We have collected the number of commits per release to get a better impression on the team’s activity per release:
While Xtext’s Neon release 2.10 was mostly a smaller bug fix release, the activity for 2.11 notably increased. This clearly shows how vital the Xtext project is.
Language Server Protocol
Xtext’s most notable new feature the support of the Language Server Protocol (LSP). This enables Xtext DSLs to be used in any editor supporting the LSP. Currently this includes Visual Studio Code, Eclipse Che and Eclipse Orion is following. Other editors are working on the integration of the protocol’s client side. This big step could only happen because of the brand new project LSP4J, that enabled the java world to participate in the LSP.
We have prepared an example for a DSL language server that integrates with VS Code in the GitHub repo xtext-languageserver-example.
We are paying more attention on the user experience and listen to our users. While power users appreciate Xtext’s flexibility, performance and functional richness, the less experienced and new users struggled in some areas.
Because of that we performed a usability test for Xtext’s Project Wizard together with the itemis usability engineering team. That gave us new insights on usability flaws that we were not so aware of. As a result, we made some improvements on the Advanced Configuration page and its messages.
We plan to continue our work with the usability engineers to identify more potential for improvements.
Xbase and Xtend code is automatically generated to Java. Most of this work is done by the XbaseCompiler class, while the XtendCompiler is deriving from it and adds Xtend specific stuff. The code is meant to be compilable, debuggable and performant, but not necessarily readable.
The compiler was optimized to reduce the amount of synthetic variables in favor of readability now. In this diff you can see what Xtend compiled from the same code before (red) and after (green). As you can see the code becomes far more compact and readability. On the other hand the more verbose code could be more debuggable. We plan to make the “verbosity” of the compiled code configurable later, but leave with the compact mode as default.
Other optimizations on the compiler increase the performance for template expressions and robustness.
Deprecation of the old generator infrastructure
Xtext’s generator was initially build with Xpand. With Xtext 2.9 the language generator was reimplemented with Xtend, with a new project layout and generator workflow. While Xtext keeps the old generator for backward compatibility, it has now been deprecated and we encourage users to switch to the new generator. New extensions and improvements to the generator won’t be backported to the old one.
Note that we can not remove the old generator from Xtext for backward compatibility. For the case that Xtext gets a major upgrade to Xtext 3.0, we will definitely remove that code. At the moment there are no concrete plans about a version 3, we will continue with 2.12 for Eclipse Oxygen.
Advanced Oomph Setup
The repository split and increasing usage of Gradle for the Xtext build had many implications on the development environment. Xtext provides a setup for Oomph which has been changed to support these changes and add some other benefits. Provisioning an Xtext development environment has never been easier!
The updated set up considers the splitted repository structure and enables a specific selection on the project set that a developer works on. Or the other way around: It allows to leave out projects that are not in the developer’s scope.
Xtext uses the recently released Buildship 2.0 feature for Gradle support. However, Xtext’s multi-repository multi-project structure hit limitations of the Buildship tooling in regards of cross-repository project relationship resolution. This implied the introduction of a new umbrella project and scripting of Buildship preferences generation. The Oomph setup takes care of these details, so developers don’t have to be bothered with them.
Xtext 2.11 is a major shift in the frameworks history. Especially its support for the Language Server Protocol will be a game changer that opens DSLs for increasing more editors. Besides that this release provides a ton of bug fixes and small improvements, especially which affect stability, performance and usability. Xtend users will appreciate the improved Java code generated from Xtend classes.
Go and get the new release now. The Xtext team is happily awaiting your feedback!