Why is Eclipse 4 better than Eclipse 3

So there are many people around asking themselves why the hell did they rewrite the whole foundation of the Eclipse SDK while I as a user of the SDK don’t gain any benefits on first sight.

I’m try to collect some of the reasons why I think Eclipse 4 is superior to Eclipse 3 (and Eclipse 3 RCP) in the next few weeks and cover them in a blog post like this one.

Easier to add features / fix bugs

I’ve just released a feature to Eclipse 4 which took me no more than 5 minutes to implement (Bug 355763). I’ve also worked on the same feature in 3.x and there it took me around 2 days to understand how this whole thing works and another few days coming up with a fix which finally could not be applied because it didn’t worked in some corner cases (Bug 355750).

Advantage 1: Committers can fix bugs much faster

Not every feature is hardcoded in the workbench plugin

Many features like e.g. the collapsing of empty containers is not hard coded into the workbench code itself but implemented with so called addons who listen to the workbench application model and react upon changes in there (e.g. the removal of children in a container, …) but because the thing is an addon and you miss the durable feature (like many people did in 3.x for a long time) and don’t find a committer to implement it for you can now do it your own by replacing only a small discrete piece of code.

Advantage 2: Developers can add features / fix problems themselves without waiting for up-stream committers to implement it for them
Advantage 3: We the platform committers don’t own all the worlds problems because we have to implement it in our code and have to deal with the maintenance

JavaFx + xtend a sensational perfect match

So I couldn’t resist – and just for Chris Aniszczyk­čśë – another blog post on this topic. So I wrapped my head around this builder stuff of xtend and with the sources provided by Sven at github I managed to write a small builder for JavaFX.

Here’s the builder:

and this an resulting example code:

Now the problem is that make a builder for all FXClasses one uses is not really a practical thing but the nice thing is that most of them are Beans so I added a builder method that accepts a class as the first parameter and uses reflection to create an instance.

and even autocompleteing still works in this case:

I pushed the sources to my github repo. Maybe there’s a better solution to the reflection workaround I used but currently this looks quite good.

JavaFX + xtend a perfect match

So after having used xtend for a while as a pure templating language I thought it’s time to explore how it can be used when programming JavaFX.

JavaFX 2.x API is already designed to be used for lambda expression support which will come with Java 8 so e.g. all event handlers accept a SAM type as their sole parameter. xtend already provides lambda expressions and so one can write less code.


b.setOnAction(new EventHandler<ActionEvent>() {
  public void handle(ActionEvent arg0) {
    // Some expression goes here


b.setOnAction [
  // Some expression goes here

// or if you have an equal-sign fetish­čÖé
b.onAction = [
  // Some expression goes here

The same is true for bean properties which look like this:


Button b = new Button();
b.setText("Say hello");
String v = b.getText();


val b = new Button();
b.text = "Say hello"
val v = b.text;

The complete source code looks like this:

I’ve recorded a small video showing how to create a JavaFX project which uses xtend to the final exported application. The video highlights the amazing new feature the itemis guys added to their latest milestones when running your xtend code in debug mode – good job.

I’ll try to explore more xtend features like using the builder support but I need to first understand how this really works (too bad I missed their EclipseCon tutorial)