this is a write up of a presentation I gave together with Sebastian last week at XtextCON. It is about our future plans of Xtext. But before we talk about the future I would like to start with a quick summary of ...
The Status Quo
Xtext is in development for seven years now. We have always been between 6 and 10 active developers, currently being 9. With a total LOC of 5.747.523 our code base is huge. However you have to take into account that we not only check in generated code (it sometimes helps us to spot problems) but have many, many tests. All in all there is 27.539 usages of @Test which are executed in many different scenarios and against different platforms. All together we count over 180k unit tests.
This kind of test coverage together with a passion for code quality is key keep a software system maintainable and extensible after years.
Xtext 2.8.x
In the coming week we will release 2.8.3, a bugfix version of the 2.8.x stream that introduced many cool new features. With version 2.8.3 we have fixed over 120 bugs and improved quality furthermore. This is also the release that will be part of Eclipse Mars.
Error ReportingNot sure if you have noticed, but with Mars also comes the new error reporting tool, an initiative by the developers behind Eclipse Code Recommenders. It basically asks you to automatically send in error reports for all kinds of exceptions and UI freezes you experience when working with Eclipse. Although it is not yet included in the Luna SR2 packages we already got many helpful tickets through that feature from the milestone builds. Please, turn this feature on and provide as much information as possible. It really helps!
What about future releases?
To figure our what the community demands, we did a survey. Thanks for everyone who attended! The survey was targeted at Xtext users, and besides some more demographic questions, the most important question was:
"What should be changed or improved?"
The answers included a lot of valuable feedback. Most of them could be assigned to one of the following four themes. I put some of the original answers and comments from the survey on the slides.
People asked for more documentation, specifically around Xbase and in the code (i.e. JavaDoc). Also many asked for an overview chapter where a bird's eye view of the architecture and life cycles is explained. We agree that these parts should be added and enhanced and have put it on our agenda. Fortunately the documentation is now written in markdown and change is only one pull-request away (for everyone ;-)).
Performance has always been high on our list and for every release we spend a lot of time on profiling and optimization. If you suffer from performance problems, first make sure, that you are on the latest version. Performance makes huge steps from release to release.
Here is some of the improvements we have been working on lately:
- Do nothing in UI thread - computations of any UI services have been moved to background jobs, such that nothing blocks the user.
- Cancel everything - all UI services, such as outline, mark occurences, semantic highlighting, etc. get canceled on change (i.e. as you type). Since the state is outdated we can stop waste CPU cycles on it.
- Cancelable builds - also incremental builds now get automatically canceled, when another change comes in.
- Storaged Resources - Xtext can write fully resolved and computed resources to disk in a binary format, so it can later be loaded again quickly
- Incremental standalone compilation (new in 2.9) - The eclipse builder has always been incremental. Now Xtext also has an incremental standalone compiler, that together with a running demon ensures super slick incremental compilation of changed files.
Of course, improving performance is never done!
Continuous integration with Xtext and Xtext-based languages has traditionally been a bit of a pain. This is mostly because we started out as an Eclipse only project, and building Eclipse plug-ins is "different". The Xtext project has had a continuous integration build for years, but our build infrastructure is not exactly simple. Targeting different platforms requires a bit of a zoo of build technologies on our side, which should not be necessary for clients. Since almost two years now, there is Maven support, including a plug-in to run your language in an arbitrary maven build. The same has been added for Gradle as well.
The next step is to allow for different project layouts, i.e. Eclipse vs. Maven/Gradle layout and allow for developing Xtext languages without any kind of Eclipse dependency. Which brings us to the last theme.
Xtext is a language framework that has significantly lowered the barrier to develop programming languages and external domain-specific languages. One of the sweet things is the cool Eclipse support you get. However even if you only need a compiler for a language without any Eclipse tooling the Xtext framework provides you with rich abstractions for scoping, indexing, incremental compilation and more. With the next release (version 2.9) it should be possible to create a runtime project only, without any Eclipse dependencies and without the necessity to deal with OSGi or eclipse plug-in mechanism. Our goal is to allow for vanilla Java projects with a normal Gradle or Maven build.
For the IDE part, we are working on supporting web editors and IntelliJ IDEA specifically at the moment. But maybe even more important in the long run, is the general extraction of the IDE services from Eclipse dependencies, such that they can be reused on other platforms easily. Tom Schindl for instance already uses Xtext in JavaFX applications and we are in contact with a group that has ported Xtext to Visual Studio through IKVM.
Just to be clear: The Eclipse support stays important and will be a first class citizen for the Xtext framework in the future, too!
Summary
As you can see, the direction is a mixture of improving quality and performance, making accessibility easier but also reaching out to new platforms. I hope you find this direction as exciting as we do. We plan to release Xtext 2.9 in the last quarter of 2015. In case you want to try the current state of the web or intelliJ IDEA support, go ahead and download the recently released beta version. More betas will be released in the coming weeks / months.
So long, have fun and remember your feedback is helpful and very welcome!
