Subscribe: Sven Efftinge's Blog
Added By: Feedage Forager Feedage Grade B rated
Language: English
active annotations  active  annotation  annotations  code  eclipse  extension  idea  java  language  new  support  xtend  xtext 
Rate this Feed
Rating: 3 starRating: 3 starRating: 3 starRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Sven Efftinge's Blog

sven efftinge's blog

Updated: 2017-09-10T19:40:07.239+01:00




As many of you already noticed, we had to find a company name without 'Xtext' in it. Longer story short, we finally decided for TypeFox (it still has an 'x', ey? ;-)).  We are still all about Xtext and Xtend, of course.

The website is online now and reveals some additional details about what we do. Also we are having a blog there, which will be updated with useful content around Xtext and Xtend and more general about language engineering, code generators and so on on a regular basis. If you want to get notified about the content, there is a monthly newsletter. It will contain information about the latest blog post, upcoming Xtext and Xtend releases and upcoming events. The sign-up form is on the blog page.

Also Jan joined this month as a co-founder and there will be five more friends (Xtext committers) joining TypeFox in the coming weeks.

Finally I wanted to say thank you, for all the good wishes and the trust of our partners who already do business with us. It starts all very well and I am very thankful for that.

How do you like our logo?

Founding An Xtext Startup


First of all, I wish all of you a Happy New Year! In addition I'd like to update you about some decisions I made recently.

Since January 1st I no longer work with itemis. Instead I am founding a startup together with my friends from the Xtext team. The new company will be all about Xtext, and as such 100% dedicated to language engineering and tool development.

We want to make sure to run a healthy and sustainable open-source business. The huge success of Xtext in the past few years has shown that there is a significant market for special tool and language development and that this is even growing. We really enjoy working with so many different customers around the world and it always is a pleasure to see them getting excited about the power of Xtext. Just in case it is not clear, we will for sure invest significantly into the further development of the open-source framework.

We start by offering the classical support packages, trainings, and general consulting. That is everything you need to make sure you get the best possible results with Xtext. In future we might have some ideas for additional services and products as well. The new website will be up in a couple of days and will contain more detailed information. Stay tuned!

If you have questions, just want to chat, or want to work with us - this is my private email:

Edit: We really would like to use something with Xtext in the name (like XtextSource), but this unfortunately conflicts with the guidelines at This may come to you as a surprise, as there are companies like EclipseSource, but this is a special case as they were founded before 2005. We will come up with another good name soon. :)

Xtend: Active Annotation Processing in IntelliJ IDEA


This is a short screencast showing the use of @Accessors, @EqualsHashCode and @Data within IntelliJ IDEA 15.

See how getters, setters and other boiler plate gets eliminated in Xtend.

Note, that unlike case classes in Scala or data in Kotlin, in Xtend these annotations are just library. You can easily build your own!

src="" width="500" height="375" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen>

Xtext for IntelliJ IDEA - Preview


Today we've released a preview version for the upcoming IntelliJ IDEA support of Xtext. With this it is now possible to develop Xtext languages entirely in IDEA and due to the cool Gradle support in any other environment, too.

The preview plugins for IntelliJ IDEA can be installed from the following repository location:

Note that Xtext requires the latest IDEA 15 Preview build.

I've recorded a small screencast that shows what Xtext in IntellijJ IDEA looks like: src="" width="500" height="375" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen>

What I learned at JavaZone 2015


This week I was lucky to go to Oslo to attend JavaZone, which is what they say "the largest community-driven developer conference in the world".No matter that's true or not it is for sure one of the coolest conferences I have ever been to. It is generally extremely well organized and on top of that they have some really cool features like: an overflow area, where you can watch all sessions on a split screen and switch audio using a headset! different food stations, that open in the morning and serve delicious food all day! recordings of all sessions, uploaded to vimeo and made available in a couple of hours! ... many more cool things (e.g. I got a Raspberry Pi as a Sopeaker's present :-))But that such a conference is all about the people and the content, which was equally great:WednesdayThe first day I started with a talk about alternative implementations for collections. The speaker maintains a library with something he called a gap list, that had some clever techniques to make positional insertion cheaper (compared to ArrayList). It made sense to me and the measurements looked good, although there's a last bit of sceptic on my side, as he did the measurements "on his own".The next session was the one about Neo4J by Michael Hunger. I already knew Neo4J a bit as did some examples using Xtend some time ago, but it was still very interesting. He showed a cool demo, where he imported data from twitter, github and stackoverflow and joined it together in the database. Also I didn't know the cool web frontend he used, that lets you enter some Cipher code (the Neo4J query language) and shows the results as dynamic diagrams. Cipher btw. is implemented using Scala's parboiled. They really should consider reimplementing it with Xtext, so they get proper editors for free ;-)Next up was Rafael Winterhalter, talking about his open-source library "Byte Buddy". Byte Buddy is a bytecode library, that comes with builder APIs and some hooks for agents to make it easier to do byte code generation at runtime. The talk was well presented and very interesting. I especially liked the style of his slides, which were very reduced and calm (I'm kind of sick of stockimage-heavy slide decks - I know I use them myself too much :-))The fourth talk was "How to make your code sustainable" by Christin Gorman. The room was very crowded and it seems like most people enjoyed that talk very much, as she was very enthusiastic. For me it was a bit too superficial and the enthusiasm was tiring me at some point. (nitpicking on)Also there were strange code examples that just wouldn't compile (nitpicking off)."The Rule of Three" with Kevlin Henney came next. I went to the room, and of course it was overflown. It's Kevlin Henney after all. So I got to try the overflow area for the first time, and it worked flawlessly (as everything else at this conference). The talk was cool, it's always a pleasure listening to him, although he was doing jokes on IDEs :-). I didn't learn many new things (maybe some quotes I have forgotten about now already) but it was super entertaining.Next up it was my turn to give an introduction to Xtext. The talk went well I think, there were at least some very excited attendees approaching me after the session. As always most of the talk is a demo. It has been recorded and you can watch it here (find all the other talks in the same album).After that talk I went to the hotel to watch the silly Apple Event (what a waste of time!) and were too tired to get up and go back to the #AweZone party. Oh my, I'm getting old!On the bright side, I was able to get some work done in the evening and wouldn't have a hangover on ...ThursdayI took the time to get in touch with some people and also get more work done. Also I found some cozy places on the conference site and enjoyed the great coffee, food, and ice cream along with some coding.The only talk I attended was Neal Ford's take on "Microservices". As you might know micr[...]

The Future of Xtext


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[...]

Xtext moved to Github


I'm just back from EclipseCon and XtextDay in San Francisco, where we announced the new 2.8.0 release of Xtext and Xtend among some other interesting developments. One of those is our...Move to GithubIn order to simplify the contributor's story, Xtext is taking part in the "social coding initiative" of the eclipse foundation, and the primary git repository has been moved over to github. As a consequence we will no longer use gerrit for code reviews but github pull requests. Also it now makes more sense to fork, watch and star our repository.Xtext is of course still an Eclipse project!Changing documentation in two clicksThe website has been reimplemented in jekyll and the entire documentation is now written in github-flavored markdown. A link on every page that says 'edit on github' will open up a markdown editor on github, where anybody can do changes and propose them in form of a pull-request with a second click. This allows for wiki-style turnarounds but with a review and CLA check in it.Just go try it out :-)Automated setupWhile documentation and website improvements can be made in the browser, you usually want to run some of our over 30.000 unit tests when you did code changes, or be able to compile and debug code. With a big project like Xtext that targets multiple platforms, the setup of a workspace and the corresponding tools is unfortunately not exactly simple. But fear not, this is all automated, thanks to an oomph setup. So even here it is only a couple of clicks until you have a fully working setup, that includes an IDE, the workspace, correct target platform, the team's workspace preferences and so on. Just everything you need and everything like we committer have it.Code contributionsThe team has many active committers that are very happy to review your high-quality pull-requests. If you want to start working on something it would be best if you pick up one of the bugzillas flagged with 'v2.9' or whatever the upcoming release is in case you read this post at a later point in time. This is how we schedule the things we agreed on working on.[...]

Auto-GWT - Boilerplate Free GWT Programming


Maybe not especially new for everybody, but: GWT is NOT dead!

I've been at the GWT.create conference yesterday, a two-day conference on GWT only that took place in San Jose last week and this week in Munich. With over 400 attendees it was sold out. If that is not enough evidence of the liveliness of the project, you may have missed that Google runs huge projects on GWT. The latest one is Google Inbox. Add all the nice improvements (like increased compile speed) the latest releases have to offer and you will conclude that GWT is the best way to write browser apps in Java or any JVM language. The generated JavaScript code is highly optimized and runs even much faster than typical hand-written JavaScript code.

I had the pleasure to present the new Auto-GWT library we have built for GWT together with my colleague Anton. Thanks to all the attendees for the great questions and the overwhelmingly positive feedback. As a kind of wrap up after the conference I have uploaded the slides, the demo and the Auto-GWT project.

You can find all necessary information on the project's website :
Forks and pull requests are very welcome!

Auto-GWT in action:

src="//" width="500" height="281" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen>

Slides from GWT.create:

src="//" width="425" height="355" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen>

XtextDay and EclipseCon San Francisco 2015


In case you've missed it, we are organizing a so called XtextDay co-located with EclipseCon 2015. The program is already online for a couple of weeks: Sebastian and I will start the day talking about the newest developments (e.g. Intellij IDEA support, web editor support, incremental standalone builders, etc.). After that we will hear how Xtext languages are used to design REST APIs. In the afternoon we have in-depth sessions on Xbase, performance and scoping, and after the coffee break we will learn how a silicon valley company use Xtext to build a commercial product for designing systems on a chip (IoT). The full program details can be found here. But that's not all.. Additional Xtext content at EclipseConAlthough it's possible to register only for the XtextDay, I recommend to book the whole EclipseCon conference as it is not only an awesome community event where you will find many new friends, but in addition to the XtextDay, there is some Xtext-related content there as well. It starts with a beginner's tutorial on Monday, which is a good preparation for the technically deeper talks following. In addition to the XtextDay and the tutorial we have: Building an IDE for Apache Cassandra with Eclipse RCP, e4 and Xtext by Michael Figuiere of DataStax. Datastax is the company behind the Cassandra database, and he's going to talk about the product they've built with Xtext. Diagrams, Xtext and UX by Jan Koehnlein. Jan is an Xtext committer and he will show a lightweight opeen-source diagram viewer framework based on JavaFX. Generating Business Applications from Executable Models Using Xtend and Eclipse UML2 by Raphael Chaves. Not strictly Xtext related, but a talk about a code generator built with Xtend. Model Your Business Like You're In 2015 by Adrian Mos. Shows a domain-specific approach to business process modelling using lots of Eclipse technologies, including Xtext. Sirius + Xtext = ♥ by Maxime Porhel. As the title already suggests, this talks is about integrating the graphical modelling technology Sirius with Xtext. System testing scientific software by Torkild U. Resheim. In this presentation Torkild will show how they used Xtext at the Norwegian Marine Research Institue (MARINTEK) to describe tests for marine operation simulations. The Making of XRobots by Jan Koehnlein and Miro Spoenemann. Jan and Miro (who is btw. a new committer to Xtext) are going to show how our XRobots game was built. You will see it's a really nerdy mash-up of strange technologies :-). Of course we will have the XRobots at our booth for the whole conference, let's see who will come up with the winner robot this time! So quite some content in addition to XtextDay. If you consider using Xtext for something or you are already using it, then you should definitely come and join the sessions, discussions and party! :-) [...]

Eclipse Xtext goes IntelliJ IDEA


The Xtext framework has been in development for six years now. With a team size between five and nine people (we are now at nine) plus many contributors working on it, it has become a successful framework for development of domain specific languages and programming languages in general. From parsers, linkers and compilers to interpreters, type-checkers and full IDE-support, the framework covers everything a grown up language infrastructure needs. So far however, the IDE part has been Eclipse-only. This will change now.

The Eclipse based IDE support of Xtext is very mature. We will further improve robustness and performance and might add one or the other feature in the future, but the Eclipse-support really has come to a state where not much is missing. Personally I like Eclipse as a code base as well as a tool, but the reduced activity in the platform itself has resulted in a noticeable decline of excitement and we see more and more devs preferring IntelliJ IDEA for their Java development. Also there are many shops where the IDE is not set, so developers can choose. Those teams with mixed IDEs suffer from lacking DSL tool support for their non-Eclipse IDEs, of course.

Long story short, this summer we started working on support for IntelliJ IDEA. It shall work without requiring duplicate implementation for the main aspects. So as an Xtext user you can still work against the core Xtext APIs and any existing Xtext language is going to work in IDEA without further ado. A thin layer translates the information to IntelliJ’s concepts (PSI, etc.). Of course everything is composed with dependency injection, such that IntelliJ-specific optimisations and customisations are still possible. The work is coming along nicely and we hope that a first public beta version can be released early next year. Of course this includes IntelliJ IDEA support for Xtend as well!

Here’s a short screencast showing a bit what’s already working.

src="//" width="500" height="326" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen>

Xtext on IntelliJ IDEA from Xtext Team on Vimeo.

More platforms to come

Although the current focus is IntelliJ (and Eclipse of course) we think in the long term it is important for the Xtext framework to support other platforms as well. Next up will be serious support for web browsers, which is especially interesting for the many DSLs targeting non-developers (i.e. “business DSLs”).

XtextCON Update


XtextCON 2014 is still 40 days away, but I have to announce that ...

We are sold out

Initially I planned for 80 attendees. It turned out that was much too small, so we have added 30 more tickets as the event and venue can handle 110 people without problems. Today we have 112 registrations and since I want to make sure that everyone has an excellent time at this first XtextCON we closed registration today. I'm really sorry if you haven't booked yet but wanted to do so. We'll likely do an XtextCON next year again. 

New Sessions

We have added some really cool new sessions. All in all XtextCON will feature 18 Speakers and 28 sessions in two tracks. The added sessions are:
 - Xtext + Sirius : <3 (Cedric Brun)
 - Xtext + CDO - Does it blend? (Stefan Winkler)
 - Oomph - Automatically Provision a Project-Specifc IDE (Eike Stepper, Ed Merks)
 - 3D Modeling with Xtext (Martin Nilsson, Esa Ryhänen)
 - Handle Based Models for Xtext with Handly (Vladimir Piskarev)

Checkout the updated program.

Announcing XtextCON 2014


I'm super stoked to announce the first edition of XtextCON, an annual conference on Eclipse Xtext.

With close to 6000 newsgroup items per year the Xtext community is one of the largest and most active at Although conferences such as EclipseCON feature many talks on Xtext, they usually cannot go into much detail as those conferences are targeting many different technologies. XtextCON should be an event where we can dive deeper. It is a community event and is meant to help users solving technical problems, get feedback on design ideas and learn about advanced topics.
XextCON is targeting beginners as well as advanced users. Beginners get the opportunity to attend a one-day workshop before the conference. So they get up to speed for the deeper talks at the main conference while those who are experienced with Xtext but feel like there knowledge is a bit outdated will get a quicker heads-up in the morning of day one.
The program covers many different aspects such as scoping, linking, how the index works, how to build type system, and many more. Also we have talks on graphical editing or generally how to improve the performance of your languages, code generators and IDEs. Btw: Thanks to the many attendees of the survey, it helped a lot to put the program together.

Xtext Clinic

In addition to the two main tracks, we will run a special Xtext-clinic on both days, where attendees get the opportunity to discuss their individual Xtext-related issues with committers and experts.

The Location

The event takes place in Kiel at the ATLANTIC hotel, which sits directly at the beautiful harbour of Kiel face to face with our office. Kiel is a small city in northern Germany at the baltic sea and May is the best time to visit it. The area around it is one of the most beautiful places at this time.
It could be a good idea to bring your family and spend the weekend here as well.
So, check out more details on the website and make sure to make a reservation early. Tickets are limited! Looking forward to see you there!

Quick Survey about XtextCON


Dear Xtext-Community!

we think it's time for an annual meet-up / conference ... what ever, solely on Xtext. The first one is planned to take place on May 26 and 27 and I'm in the process of building a website including the program. For that I need your help :-)

I have compiled a list of Xtext-related topics, and would like to ask you to give feedback about which you find interesting, and also which are missing. So, in case consider attending XtextCon, please take the survey below (it's just one question). Also please forward to you colleagues. the more feedback we have the better the program can be.

Also: If you are interested in presenting at XtextCON, please drop me a mail (xtextcon at itemis dot com). Thanks! :-)

Xtend & Android - Sneak Preview


In preparation of upcoming presentations for EclipseCon and W-JAX on that matter, I dived deeper into Android development and worked improving common programming idioms in that area. I'm contributing to Toby Kurien's Xtendroid and in this post I want to give you an idea of how Xtend can help developing Android applications.

Binding Android Layouts to Code

In Android user interfaces are mostly developed using Android's XML format for layouts. You can program them using Java but that's not what people do most of the time for various reasons. One of course being the verbosity of Java, but also the tools around the layout XML are quite helpful, especially when you have to deal with internationalization and need to support a wide range of devices.

Of course XML alone doesn't cut it which is why you have to bind the stuff declared in XML to Java code somehow in order to add listeners and other dynamic functionality. By default this is quite cumbersome as you have to deal with untyped code (cast) and a lot of integer constants. Some thirdparty frameworks try to reduce this problem by "injecting" the needed views reflectively, but that doesn't really help much. It's still not type safe and therefore error prone and you'll have to redeclare (i.e. duplicate) what you have declared in XML already.

With Xtend you can use an active annotation, which just points to the xml layout file. An active annoation is a macro annotation, which allows for participating in the compilation. This one will look into the referenced layout XML and declare local fields for any elements attributed with an '@id'. It also will derive an interface with all onclick methods declared in XML and make the current class implement it. As a result there is zero duplication and 100% type safety. The best is that the IDE knows about the changes and provides you with respective compilation problems, quick fixes, content assist and also the outline shows what has been derived from the XML layout file.

This is best shown in a small demo:

src="//" width="500" height="281" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen>

Xtend and Android - Binding XML Layout and Code from Xtext Team on Vimeo.

Better I18n in Java


Internationalization is not the most loved topic for Java developers. This is merely because it makes code less readable and introduces the need to work with property files and constants. As a result there is no static typing in that area and we are in need to get supported by tools, such as IDEs. In this blog post I want to show how this can be elegantly solved with Xtend. I18n - The JDK Way The JDK offers well working facilities for externalizing messages and formatting values such as dates and currencies in a proper localized way. For externalizing messages the class ResourceBundle is your friend, as it not only reads and parses property files but also supports flexible way of how property values are looked up based on Locales. The other interesting bit is the MessageFormat hierarchy which contains strategies to turn data types into localized strings. The provided functionality is very powerful but enforces a cumbersome programming model. The standard way is to have a bunch of property files and whenever you need to get the contained values you use a ResourceBundle which has to be created like this: ResourceBundle messages = ResourceBundle.getBundle("MyMessages", localeToUse); Now you obtain the messages using the property keys, which are just strings. To minimize very likely spelling problems and it is good practice to have a declaring all the keys as constants. Then you only have to declare them once in the code and once for each property file.public class MyMessagesKeys { public final static GREETING = "greeting"; ...} Clients can access the values using the constants :messages.getString(MyMessagesKeys.MY_KEY);A common requirement and feature is to have variables in the messages which should provided by the program. These arguments can even be of different types, where the MessageFormat types come in. But again the Java compiler doesn't know if there are any arguments, nor how many and of which types they are. So you are back in untyped land and will learn about your errors only at runtime.Let's see how we can improve the API for the JDK classes, such that we get rid of all the duplication and weakly typed access. DRY With Xtend Xtend is not a language which is meant to be used instead of Java, but is an extension to Java. You should use it in places where Java just doesn't cut it, like in this example. In the following we're going to built a statically typed API to be used from Java by means of an active annotation. The basic idea is, that we make the compiler turn a constant containing a message into a Java facade and a corresponding properties file. Consider the following declaration of messages:@Externalized class MyMessages { val GREETING = "Hello {0}!" val DATE_AND_LOCATION = "Today is {0,date} and you are in {1}"}This is all the developer should need to declare. Now we implement an active annotation, that turns the field declarations into static methods. It even adds typed arguments for the placeholders in the messages. That is the generated Java provides the following sigatures:// Generated Java signatures/** * Hello {0}! */public static String GREETING(String arg0) { ... }/** * Today is {0,date} and you are in {1} */public static String DATE_AND_LOCATION(Date arg0, String arg1) { ... }The actual values are written to a *.properties file and the implementation of the static methods use a ResourceBundler to look them up. So in case you need a locale-specific translation, you only need to add an additional *.properties file. Even that could be easily validated for miss-spelled or non declared keys. But I'll leave this feature as an exercise for other people :-). Java clients can now access the messages in a statically typed way,[...]

Xtend and Xtext 2.4.3 Is Out!


We have released version 2.4.3 of Xtext and Xtend. As you can see by the minor increment it's a fully backwards compatible bugfix release. For this release more than 120 bugzillas have been solved, among them some very important enhancements:

Active Annotations : New Provisional File API

The still provisional active annotations API has gotten a new compiler phase and API which allows users to interact with the file system during compilation. This on the one hand is useful to generate signatures based on configuration files or generally project resources and on the other hand allows to update or fully generate such resources based on code. I have written a separate blog post describing an example.

Active Annotations : Polishing, Fixes and Constrain Enforcements

The API has been further refined and polished. Many contracts already described in the JavaDoc are now enforced such that you get early feedback when violating them.

Full Support For Unicode

Xtend now fully supports Unicode in identifiers. When translated to Java unicode characters get escaped only when the target encoding cannot display them. The same mechanism is used for string literals. We haven't pulled this up to Xbase for now, because it would have required clients to regenerate their language infrastructure. This is planned for the next release (2.5).

Content Assist

There were some important context where content assist didn't work. That has been fixed. Also some performance optimizations have been made. That said it's still not where we want it to be. So stay tuned.

Auto Edit

Severe performance problems with large documents have been identified and solved.

Rename Refactoring, Organize Imports, Formatting

Various enhancements have been made and bugs have been fixed in this area.

Xcore Support

There were some URI-related problems with using Xcore, which in some situations were a real showstopper. They are fixed now.

URI Handling

A problem that was introduced with 2.4.2, which made the build fail with URI comparison exception, has been fixed. As a result when generating an Xtext language the *.ecore and *.genmodel files are now generated to a different location.

... and many more

Check the full list.

Five good reasons to port your code generator to Xtend


If you happen to have an existing code generator written in Xpand or some other (template) language, here are five good reasons why you should migrate to Xtend.Xtend is fastCode generation adds to the development turn around time. We all know it : tools can slow us down. They take their share of CPU cycles during the daily development and all that automation is not worth it, if you have to wait for your machine all day long. Many template languages are interpreted and are therefore rather slow as they cannot benefit from optimizations done during compilation. Code generators written in these languages suffer from that of course, and if you don't care you can easily multiply the time your build takes with a slow code generator.Xtend code is translated to readable and idomatic Java code. It runs as fast as Java, which is *very* fast and there's no additional overhead nor dependencies at runtime. Rough measures have shown that code generators implemented with Xtend are up to ten times faster then the equivalent Xpand version.Xtend is debuggableCode generators, just like any other software system, have a tendency to get a bit complex over time. It's not so funny to find and fix a bug in a real world code generator without any debugging support. Unfortunately that's the situation with most template languages : They don't have any good debugging support.As Xtend code is translated to readable Java code you can always use the advanced Java debugging tools you are used to. Additionally the Eclipse debugger lets you choose whether you want to debug through the Xtend source code or the generated Java code. You can even switch back and forth during the same debug session (see the screenshot).Better IDE SupportXtend's Eclipse support is propably the most advanced after Java. The integration between Xtend and Java is seamless : Navigation, Call Hierarchies and even cross language refactorings just work. And Xtend features the whole Java type system and gives you errors and warnings as you type.Template Expressions and Grey-Space SupportIn contrast to typical template languages such as Xpand, templates in Xtend are expressions which yield some value. This allows for composing multiple templates and lets you pass the results around and process them.A unique feature to Xtend is the greyspace support. It solves the conflict between pretty printing a template and pretty printing the to-be-generated output. Common template languages cannot distinguish between indentation meant for the template and indentation meant for the output. Xtend can. Here's an example (note the different coloring of whitespace):Better ExtendabilityIn order to reuse a code generator and adapt it to the needs of a particular project, you need to be able to hook into it and change certain implementation details. In Xpand this was supported through AOP: You could hook into any template invocation and do what seems fit.Although very flexible, this approach is also very fragile. The original code generator cannot be evolved, since clients might hook into any template call and you break them easily. Even worse you don't get any compile-time feedback about the broken extension hook.With Xtend you can use dependency injection together with extension providers. No AOP anymore and the solutions is even faster and statically typed. If you need to exchange some implementation, just reconfigure your dependency injection configuration and your are good.SummaryThere are many more advantages and cool features in Xtend, but I hope the five listed here are convincing enough. allowfullscreen="" frameborder="0" height="356" marginheight="0" marginwidth="0"[...]

Xtend's Extension Providers


Xtend supports extension methods very similar to how they are supported by C#. The basic idea is to make static methods available as instance method on the first argument's type. Example : import static extension java.util.Collections.*...// we can use static methods from Collections like this val maxValue = myCollection.max // calls Collections.max(myCollection)val minValue = myCollection.min // calls Collections.min(myCollection)... This makes code much more readable as you don't have to read inside out, but can read from left to right. Also the discoverabilty of available features via content assist works much better. But of course using static methods all over the place is problematic, as you bind your code to the implementation which makes it hard to test and to reconfigure for different situations (e.g. use a different database system). Enter Extension Providers! In Xtend you can put the extension keyword to a local field or a parameter. This will make its instance methods available on the first parameter's type. I'll explain that with an example using JPA and Java EE. // Java code@PersistenceContextEntityManager empublic LineItem createLineItem(Order order, Product product, int quantity) { LineItem li = new LineItem(order, product, quantity); order.getLineItems().add(li); em.persist(li); return li;}public void removeOrder(Integer orderId) { Order order = em.find(Order.class, orderId); em.remove(order);} If you add the keyword extension to the field declaration, the instance methods of the PersistenceManager get projected onto the entities. So you no longer have to write em.persist(li) but can just write li.persist: @PersistenceContext extension EntityManagerdef createLineItem(Order order, Product product, int quantity) { val li = new LineItem(order, product, quantity) order.lineItems += li li.persist return li}def removeOrder(Integer orderId) { val order = Order.find(orderId) order.remove} Extension provider allow for adding layer specific functionality to any classes in a non-invasive way. And you don't have to use static methods for that. Better APIs with Extension Providers When designing an API, you can make it very easy for the clients to have the right extension providers on the scope.One possibility is to provide an abstract base class which contains visibly extension fields: abstract class AbstractDao { @PersistenceContext protected extension EntityManager em; }class Concrete extends AbstractDao { // use extension methods from EntityManager} If you don't like inheritance that much, another approach is to mark a parameter of an abstract method with the extension keyword.interface JPACallBack { def void doStuff(extension EntityManager em)} When implementing that method, the IDE will automatically add the extension keword for you. The active annotations API uses that idiom. Note that in case you define the abstract class or the interface in Java, you can add the @Extension annotation instead of the keyword. IDE SupportSometimes the reader might be a bit unsure where a certain member has been declared. Of course the hover as well as navigation always shows the correct declaration. In addition the semantic coloring highlights extension methods ... ...and you can even inspect the desugared version of an expression in the hover : [...]

Working With JSON Data From Java


UPDATE : I have uploaded the example to github : JSONized@Github.I am preparing excercises for the Xtend tutorial Sebastian and I will be giving on Monday at EclipseCon.  For one excercise we parse an itunes music library in JSON format in order to execute different queries on that data. Of course the data is well structured, so why not adding a thin typed facade over the generic JSON objects?   I've built a little active annotation which let's you do the following: Step 1: Find some Data Let’s take data from Yahoo as an example. The data contains the most popular new album releases. Here's the first album:{ "query": { "count": 24, "created": "2013-03-21T20:13:42Z", "lang": "en-US", "results": { "Release": [ { "UPC": "602527291567", "explicit": "0", "flags": "2", "id": "218641405", "label": "Streamline/Interscope/Kon Live", "rating": "-1", "releaseDate": "2009-11-23T08:00:00Z", "releaseYear": "2009", "rights": "160", "title": "The Fame Monster", "typeID": "2", "url": "", "Artist": { "catzillaID": "0", "flags": "115202", "hotzillaID": "1810013384", "id": "58959115", "name": "Lady Gaga", "rating": "-1", "trackCount": "172", "url": "", "website": "" }, "ItemInfo": { "ChartPosition": { "last": "1", "this": "1" } } },.... } Step 2: Copy the example data into a @Jsonized annotation:@Jsonized('{ "query": { "count": 24, "created": "2013-03-21T20:13:42Z", "lang": "en-US", "results": { "Release": [ { "UPC": "602527291567", "explicit": "0", "flags": "2", "id": "218641405", "label": "Streamline/Interscope/Kon Live", "rating": "-1", "releaseDate": "2009-11-23T08:00:00Z", "releaseYear": "2009", "rights": "160", "title": "The Fame Monster", "typeID": "2", "url": "", "Artist": { "catzillaID": "0", "flags": "115202", "hotzillaID": "1810013384", "id": "58959115", "name": "Lady Gaga", "rating": "-1", "trackCount": "172", "url": "", "website": "" }, "ItemInfo": { "ChartPosition": { "last": "1", "now": "1" } } }] } }}')class MusicReleases { // empty} Step 3: Enjoy statically-typed accessor methods!The annotation will create getters and setters derived from the example data. It's just a super thin layer and you have full access to the underlying JsonObject if you want to go more dynamic. If you want to learn how to do such things, you should come to our tutorial. It's going to be fun![...]

Xtend 2.4 now available!


The committer team behind Eclipse Xtend is proud to announce the availability of Version 2.4. The new release has over 300 bug fixes. The most important enhancements are:

Active Annotations

They are Lisp-like macros for Java (or Xtend). You declare an annotation and explain to the compiler how annotated elements should be translated to Java source code. The compiler will find those annotations on the classpath and execute them during compilation. The IDE and the compiler are fully aware of how annotations contribute to the compilation process, such that content assist, navigation, linking and error messages all reflect the changes appropriately.
You have to see it in action, it is code generation like it should be! Read More

New Type System

Xtend 2.4 has gotten a whole new type system implementation, which not only improves the compilation performance but fixes many many outstanding typing issues. Also the type inference algorithm has become much smarter and even takes the control flow into account for type inference. Xtend can even infer types where other languages such as Scala fail.

Android Support

Xtend is a perfect match for Android development as it relies on the JDK and comes with very little extra dependencies. The new version has special support for debugging Android emulators and some other goodies.

New Language Features

Xtend 2.4 allows to turn local variables and parameters into extension providers, comes with a neat literal syntax for immutable collections, many new operators and some other enhancements.

New IDE Features

The Eclipse plug-in now supports formatting, more quick fixes, more refactorings, better content assist and more little gems which let you get into a smoeeth development flow.

Read the full release notes and get the release

Many Thanks

... to all the committers and contributors who have put this together: Sebastian Zarnekow, Jan Köhnlein, Dennis Hübner, Moritz Eysholdt, Holger Schill, Sebastian Benz, Knut Wannheden, Natalia Ossipova, Anton Kosyakov, Christian Hülsmeier, Stefan Oehme, Ed Merks, Benjamin Schwertfeger, Lieven Lemiengre, Hendrik Eeckhaut, Christoph Kulla, and many more!

Fun With Active Annotations: My Little REST-Server API


These days I've been playing around a lot with Xtend's new language feature addition, called Active Annotations. It's so exciting want kind of things you can do with them. Today I prototyped a nice little REST-API (code can be found at github): @HttpHandler class HelloXtend { @Get('/sayHello/:name') def sayHello() ''' Hello «name»!

Hello «name»!

''' @Get('/sayHello/:firstName/:LastName') def sayHello() ''' Hello «firstName» «LastName»!

Hello «firstName» «LastName»!

''' def static void main(String[] args) throws Exception { new Server(4711) => [ handler = new HelloXtend start join ] } } This is a single class with no further framework directly running an embedded Jetty server. The interesting part here is, that you don't have to redeclare the parameters, as the active HttpHandler annotation will automatically add them to the method. See the method is overloaded but both declare zero parameters? That's usually a compiler error, but here they actually have five resp. six parameters, because my annotation adds the parameters from the pattern in the @Get annotation as well as the original parameters from Jetty's handle method signature. Just so you can use them when needed. Not only the compiler is aware of the changes caused by the annotation, but so is the IDE. Content assist, navigation, outline views etc. just work as expected. This is how it worksThe HttpHandler implements org.eclipse.jetty.server.handler.AbstractHandler and adds a synthetic implementation of the method handle(). The effective code it adds to the class we've seen above is : // generated, synthetic Java codepublic void handle(final String target , final Request baseRequest , final HttpServletRequest request , final HttpServletResponse response) throws IOException, ServletException { { Matcher sayHelloMatcher = Pattern.compile("\\/sayHello\\/(\\w+)").matcher(target); if (sayHelloMatcher.matches()) { String name =; response.setContentType("text/html;charset=utf-8"); response.setStatus(HttpServletResponse.SC_OK); response.getWriter().println(sayHello(name, target, baseRequest, request, response)); baseRequest.setHandled(true); } } { Matcher sayHelloMatcher = Pattern.compile("\\/sayHello\\/(\\w+)\\/(\\w+)").matcher(target); if (sayHelloMatcher.matches()) { String firstName =; String LastName =; response.setContentType("text/html;charset=utf-8"); response.setStatus(HttpServletResponse.SC_OK); response.getWriter().println( sayHello(firstName, LastName, target, baseRequest, request, response)); baseRequest.setHandled(true); } }} Of course there's some room for optimizations :-) but I hope you get the idea. The implementation of the @HttpHandler and its processor is added below : @Active(typeof(HttpHandlerProcessor))annotation HttpHandler {}annotation Get { String value}class HttpHandlerProcessor implements TransformationParticipant { override doTransform(List annotatedTargetElements, [...]

Xtend's New Type System


"We are almost at a stage where only double PhDs in math & can qualify for Java compiler writers !"(Srikanth S. Adayapalam (from Eclipse JDT) on the complexity of type inference in Java 8) As Xtend implements Java's typesystem, we have to deal with exactly the same amount of complexity ... oh wait it's even better as Xtend has advanced type inference, sugared feature calls for properties, operator overloading, an implicit 'it' and extension methods (which are not only static as in C#) etc. So you better add a couple more PhDs to the mix. Write once, run ... We are used to writing key parts of our software twice (at least!). The old type system did its job in the beginning but as we added more and more corner cases and complex type inference scenarios with lambdas and such it started to become too slow and too complex to be further enhanced. Good we have a solid test suite so we actually noticed the point at which even harmless looking changes broke existing tests... To make a long story short: Last year in April we decided to rewrite it from scratch. The Lonesome HeroSebastian had some very promising ideas around a completely different architecture which would not only improve performance but also would allow everyone to better understand and debug the code again. We couldn't afford stopping all other developments and maintenance so one team member had to take the journey while the others were working on cool new features. Almost a year ago Sebastian started work on a complete rewrite. We discussed language semantics from time to time and such things but I rarely looked at the actual code. Most of the semantics were clear as it is based on the Java Language Specification and could be proved with the different Java compilers. So he was climbing this huge mountain all alone. I know it was super risky and that it's not a good idea to rely such an important part of a project on just one person. If he had failed we had wasted a year. But I knew he would do it (And if he couldn't I don't know who else could). It has been a long time and we even had to postpone the release which was initially planned for December. Finally by the end of January the new type system implementation was in a state that it could be activated and replace the old one. The switch was super smooth. It just worked. Here is the corresponding bugzilla, which has been closed just yesterday. It blocked 95 downstream bugs! Most of them are now fixed, we just had to go through them and test, verify and close them. Not only that, the performance was already as good as the old one in the beginning without any further profiling and improvements. With just a little optimisation we were already able to improve the performance by 25%.Also worth noting is, that the whole team was able to start working in the new code base after just two days of introduction. The code definitely is much easier to grasp and to debug yet covers much more of the essential complexity. Also we have an even more comprehensive test suite now. With over 20.000 unit tests you can confident that you don't accidentally break something. All tests run against the lower version bounds as well as the upper version bounds of our dependencies. There's no way software like this can be maintained and evolved without such a test suite.The new type system is an incredible piece of engineering and a huge success. It's the basis for an awesome upcoming release of Xtend with many cool new features and enhancemen[...]

Java 8 vs. Xtend


As you might know Java 8 will finally bring an important new feature to the Java programming language : Lambda Expressions, a feature already supported by many other languages, such as Xtend Xtend is a statically typed JVM language that translates to readable Java source code. It's very different to other JVM languages in the sense that aims to be a better Java by better supporting existing Java idioms and fully supporting the existing ecoystem. Xtend doesn't force you to rewrite your existing Java apps or drop your beloved and well-proven frameworks, but instead allows for using existing Java APIs in a much nicer way without any interoperability issues. In contrast to e.g. Scala or Clojure it is more like an extension to Java than a replacement. Identifying and supporting existing Java idioms is not too hard given the huge existing code base but what about the future? Will Xtend also be a better match for the upcoming Java 8 libraries which were explicitly defined for the new Java 8 lambda syntax? To find out I simply looked at Brian Goetz’s latest version of State of the Lambda : Libraries Edition and translated the contained Java code examples to Xtend. In the following you see the code for Java as written by Brian and the translation to Xtend. Both are using the exact same Java 8 APIs and contain the same amount of static type information! Example 1 Java 8: shapes.forEach(s -> { s.setColor(RED); }); Xtend: shapes.forEach[color = RED] This first example already reveals most of the important differences. First the general syntax for a lambda expression in Java is using an arrow (->), while Xtend uses squared brackets (like smalltalk). Also in Xtend a lambda expression doesn't need to be passed using braces. Although you could write shapes.forEach([color = RED]) you don't need to. In Java 8 the body of a lambda is either a block or a single expression. So whenever you need to use a statement you have to add the curly braces and semicolons. In Xtend everything is an expression and the lambda itself is already a block expression. In Xtend you can omit the declaration of a parameter name. In that case the parameter is called 'it' and is implicit (similarly to 'this'). If you want to give it a name you do it like this : shapes.forEach[ s| s.color = RED]Unrelated to Lambdas but interesting in this case: Xtend allows to use assignments to call setter methods. Example 2 Java 8: .filter(s -> s.getColor() == BLUE) .forEach(s -> { s.setColor(RED); }); Xtend: .filter[color == BLUE] .forEach[color = RED] Not too much new stuff in here. Xtend lets you omit empty parenthesis and you can call a getter using the property's name. Example 3 Java 8: List blue = .filter(s -> s.getColor() == BLUE) .into(new ArrayList<>()); Xtend: val blue = .filter[color == BLUE] .into(new ArrayList) Here we see type inference in action. While you can use the diamond operator in Java, you can leave it out in Xtend. Also the variable doesn't need to be explicitly typed as the type can be fully inferred from the right hand side. Example 4 Java 8: Set hasBlueShape = .filter(s -> s.getColor() == BLUE) .map(s -> s.getContainingBox()) .into(new HashSet<>()); Xtend: val hasBlueShape = [...]

Active Annotations Explained - JavaFX Properties


Today I'd like to give a more detailed example of how active annotations can be used to solve real world problems. Active annotations are an upcoming language feature for Eclipse Xtend, which allow you to participate in the translation step from Xtend code to Java using annotations. JavaFX Properties JavaFX comes with a very nice binding and properties framework, which allows for easy connection of model properties and widgets. It even has support for expressions, like String concatenations, which are reevaluated automatically, when a property changes. I have used it in a login screen, such that the welcome message get's updated when you type in the user name. Unfortunately defining JavaFX beans is not so nice, as it requires a lot of boilerplate. Michael Heinrichs, technical lead of JavaFX Properties, recommends the following pattern in his blog: // Java boilerplatepublic class Login { private String userName = ""; private SimpleStringProperty userNameProperty; public String getUserName() { return (this.userNameProperty != null)? this.userNameProperty.get() : this.userName; } public void setUserName(final String userName) { if (userNameProperty != null) { this.userNameProperty.set(userName); } else { this.userName = userName; } } public SimpleStringProperty userNameProperty() { if (this.userNameProperty == null) { this.userNameProperty = new SimpleStringProperty(this, "userName", this.userName); } return this.userNameProperty; } // ... same pattern for the password goes here} That's a lot of code. Given that we usually have to map a lot of properties to the UI, you don't want to write and maintain that. Code generation to the rescue? The typical solution in those scenarios is to come up with a little DSL and a code generator. In Java land we really know how to do that and there is easy to use technology available to build ... yet another entity DSL. And it's definitely a much better approach than maintaining above's code by hand, but ... The big advantage of frameworks such as Xtext is the flexibility they provide. You can build all kind of tooling and choose the right syntax for the problem. No compromises. However, there are certain classes of DSLs which really don't need or use the syntactic flexibility since they are close to class-like structures : Entities, Services, etc. In addition building an external DSL introduces a bit of an extra complexity in the development turnarounds: You'll have to maintain an Eclipse Plug-In and deploy it synchronously with the rest of your framework to all developers in your team. And just like everything else in your project, the DSL and the code generation evolve over time. So you have to keep everything in sync and deploy and install new Eclipse plug-ins every time your DSL enhances. Don't get me wrong there are many situations where the additional flexibility of Xtext is extremely useful, but for a certain class of DSLs you are better off with active annotations. JavaFX Beans with Active Annotations So let's see how we can replace JavaFX beans like the one shown above with a more readable and maintainable variant. First we replace the Java class with the following Xtend class: @FXBean class Login { String userName String password} Next we define the referenced annotation, like so: @FXBean for class { process each { inDerivedJavaClass(it) [ for (f : declaredFields.toSet) { [...]

Introducing : Active Annotations


In this article I'd like to introduce you to a new important language feature for Xtend. Xtend is a statically-typed language which compiles down to readable Java source code.Active Annotations in a NutshellActive Annotations allow for participating during the translation of Xtend code to Java source code. You basically declare an annotation and with it provide the processing instructions where you can issue errors and warnings, provide corresponding quickfixes, apply all kind of changes and enhancements to the target Java classes, introduce new Java types or even update or create ordinary text files (e.g. web.xml). To use such an annotation you just have to have it on your class path like any ordinary Java annotation.You could for instance want to have an annotation called @Entity, which turns simple classes with fields into data classes tailored for your project-specific context. You'd define and maintain the definition of what an entity is right in your project and would version and distribute it just like any other API. The IDE will be fully aware of the processing changes. Not only will errors, warnings and quickfixes be available in the IDE but also the scopes, type computation and content assistance will behave according to your processing instructions.General Use CasesLet's have a look at some use cases. Xtend already comes with two annotations, whose processing for now is hard coded into the compiler. We did so, to gain some experience with the general idea and will of course replace the hard coded version with 100% library-based annotations in a future release.One of these annotations is the @Property annotation, which translates a simple field into a Java-Bean property. That is given the following Xtend code // Xtend @Property String nameyou'll get this Java code : // Java private String name; public String getName() { return; } public void setName(String name) { = name; }The other annotation Xtend already has is @Data which translates a class with fields into a value object á la domain-driven design, i.e. it creates an immutable class with a value-based equals and hashcode implementation and a nice toString implementation. We will likely support other generic use cases such as @Delegate, which generated delegate methods for an annotated field and @Builder which will automatically derive a builder API for a set of classes. Framework-specific Use CasesYou might have seen pre-built annotations which do participate in the compilation project with other technologies. The real coolness about active annotations in Xtend is that everybody can develop their own project specific ones easily. If you want to change the behavior, just navigate to the annotation and do your changes. You will instantly see the result, since every referencing Xtend file will be re compiled on change. And it is fully transparent since everything is translated to readable Java source code!With this simplicity to develop and deploy them people will be able to use them to remove tedious structural boilerplate in many Java APIs. We for instance built two active annotations for GWT. One for remote services, which automatically derives the required interfaces and adds the required super class. Another which automatically adds fields declared in a UI-Binder XML file. You can find some slides here and the source code is on github.OutlookTod[...]