Why Eclipse e4? (the Egg Laying Woolmilkpig)

The Germans have a great expression for something that is supposed to do everything. They call it "Die Eierlegende Wollmilchsau" and it is a combination of a pig, a sheep, a cow and a chicken. It is the ultimate machine that replaces all others. How does this translate to Eclipse e4 RCP? 

We have started a cooperation with vogel/a GMBH and we have been trained by Lars in e4. The training lasts 5 days and it covers everything you need to know about creating an e4 application. E4 RCP consists of the new e4 specific technology combined with existing stuff like SWT and JFace.

The reason why I joined the course is to get up to speed with the latest RCP developments. Here is a document of my experiences and why I think e4 RCP is better than Eclipse 3 RCP.

My initial state of mind

I did not think e4 was really something that would shock me. After all, I am a seasoned RCP 3 developer and have trained many people in how to use the framework. Sure, the application model looked nice but I really did not consider it to be more than an improved manifest editor. 

I lost some interest during the development phase because I saw a number of things fall off the wagon, like XWT and OpenSocial integration.

What I did not realize is that I missed the point about core e4 technologies.  

Now that we know the gems of e4, we have decided to stop offering our courses based on the old Eclipse 3 RCP applications and completely switch over. E4 is the future for Rich Clients. and when we say Rich Clients, we don't just mean Desktop.

Let me try to explain why I think you should switch to e4. 

Reason 1, The 4th Generation of Frameworks

A 3rd generation framework, like Eclipse 3 RCP, can be viewed as a big scaffold that you use to build your application with. In contrast to scaffolds IRL, this scaffold never goes away and it will forever surround your application. 

If you use such a framework to create something, you typically extend or implement a class and implement the required methods. To give an example, to build an Eclipse View in Eclipse 3 RCP you need to extend ViewPart and because you need to do that, the scaffold needs to stay in place to support your application. 

Not only does this literally tie your application to the framework, another drawback of this mechanism is that code cannot be reused. I cannot use ViewPart outside the Eclipse RCP framework and if I wanted to re-use the user interface elements of a ViewPart inside the framework (for instance in a Wizard) then this is really hard and often requires serious refactoring.

In Eclipse e4 you do not extend or implement framework classes because you strictly work with POJO's. All hooks into the framework are based on annotations which are completely ignored if used outside of e4.

The supporting function of the e4 scaffold is much less then the old RCP. This means that an application based on e4 can be refactored to remove the framework. This is much harder in a third generation framework like Eclipse 3 RCP*.

* do I hear impossible? Going once, going twice ... 

Reason 2, No API, No Cry.

(Girls, just swap "Man" and "Woman")

An extensive knowledge of the API is required in order to comfortably interact with the features of a framework. If you are a successful user of the Eclipse 3 RCP, then I congratulate you with your tremendous capacity to store abstract information in your brain. You must not only remember the various components that you use but also know where to get them. 

This has been inverted. You no longer ask for stuff through an API but you let e4 inject it.

Suppose you want to do something simple as calling back the UI thread to update the user interface. The only correct way* in Eclipse 3 is to ask the workbench object like in this code snippet:

Display display = PlatformUI.getWorkbench().getDisplay();
display.asyncExec(runner);

This has been replaced by the following code:

@Inject Display display;

display.asyncExec(runner);

No more tedious searches to get the framework objects. You just let e4 inject everything directly into your POJO. "But I already know the API", you might say. But what about your new co-workers? (see reason 7) 

* it's true!

Reason 3, The Dynamic Application Model.

E4 uses a dynamic in-memory model of the running application. The dynamic nature of the application enables you to create, change and destroy model elements at run-time.

For example, it is very difficult to hide views from users in old RCP applications. One often needs guarding code inside the view to prevent the user from accessing it's content. There is no real concept of hiding views, especially if you also deploy your applications as plug-ins. In e4, you can iterate through your model, and based on the security level of the user you can perform actions (like deleting protected views from the model altogether)

Model elements like views and commands can be tagged. Tagging enables you to add domain specific information to the e4 application model. These tags can be read at run-time and based on their values you can apply application logic.

As an other example, you can generate a user interface completely from an empty model. Suppose you have a tool that generates an application. Instead of generating code in a static way, you could interpret information from a database and generate a user interface on the fly.

Reason 4, Dependency Injection FTW.

The e4 components are managed by the Dependency Injection Manager. The general concept of the Eclipse D.I. Manager is fairly simple; the various components of the e4 framework maintain a parented hashmap that contains all object instances that the D.I. framework can inject. This parented hashmap is called the D.I. Context.

I promise it will not hurt.

For example, the Eclipse bootstrap code is responsible for creating an instance of the Display class. This instance is then placed into the D.I. context. If any of your model objects (views, windows, menu's, handlers) require the correct instance of the Display class, it is simply injected by D.I.

Now what makes D.I. really super-super-cool and powerful is its capability to also create and maintain your own components. Consider the following class:

If you ask the D.I. framework an instance of this SomePoorClass then it will first check the D.I. Context if the object already exists. If it does not, it will create it courtesy of the @Createable annotation. Not only will it be created but also the dependencies annotated with @Inject will supplied. As an additional bonus, if any of the injected objects change in the D.I. Context, they will automatically be updated in the SomePoorClass instance. If I would tell you this during the training, you would have noticed that my voice has shifted one octave to the higher pitch. Pure enthusiasm. Super-super cool!

Reason 5, Communication

Eclipse e4 is using a global event notification system. It is based on the Equinox implementation of the OSGi Event Admin Service specification.

A special simplified class is placed on top of this implementation and is called the IEventBroker. The implementation dictates that an event can be send with send(..) or post(..). The passed parameters are the topic string, which is a "/" delimited string and an associated object called the payload.  The difference between send and post is that the former is synchronous and the latter is not. 

In addition, you can use the broker to add a listener that will be called when a topic of interest arrives. 

However, with the e4 D.I. framework in control there is really no need to register such a listener.

You can ask e4 to inject events directly into an interested method. Setting up an event listener becomes a trivial task.  

In this way you can handle your own events or tap into the events send by the framework. We all use the same global event bus.

Reason 6, GUI Independent Rendering Engines

As you know, Eclipse and SWT are married. It appeared to be a solid marriage but after Eclipse has discovered the temptations of the internet she is not so sure she want to be so monogamous as she used to be. 

The Platform developers have equipped Eclipse with a GUI independent rendering framework. 

As a result of this, there are several experiments with alternative rendering engines. Please check Kai Toedters work on Github, the e4 SWT to Web work by the RAP team, the blog describing the RAP rendering experiments of Ralf and Lars and there is a rendering engine on github for Vaadin by Rushan R. Gilmullin. 

A special mention goes to the JavaFX rendering engine by Tom Schindl. Tom has spent a lot of effort in this engine and creating JavaFX integration for Eclipse. 

This promises to take the framework you already know and love to render outside of the desktop. How cool is this?

Reason 7, Steep Learning Curve / Shameless Pitch

First let me tell you my own experience. 6 weeks ago, I had next to nothing e4 experience. Going through the vogel/a course, it took me 2 days to understand what was going on. Like I already said, I am an experienced Eclipse 3 RCP developer. It took me another week or so of fairly intense study to make me confident enough to teach e4 to others. For this study I used the e4 book Lars has written, the content available in the e4 wiki, the source code and the vast experience I already acquired through the years. 

For me, the learning curve was very steep. Meaning that I could acquire a lot of information in very little time. Since then I have seen what the training did to other experienced RCP developers and it was basically the same. After two days the e4 concepts were clear. The other days were used to learn additional framework capabilities based on the concepts.

To me and the other experienced RCP developers there was no doubt about the power and simplicity of the new framework. The concepts are totally cool.

Another experienced programmer which had never done anything with Eclipse or SWT but had developed a large Swing application, was completely convinced of the powers of Eclipse e4 and OSGi. He had fully understood the concepts and was able to create an e4 application from scratch within a couple of minutes. 

Can you do it without training. Sure. Go to Vogel/a's website and look at the wealth of information available. If that is not enough, go to the forum and ask questions. If that takes to long, buy the book. However, there is nothing like a good old crash course to erect the learning curve.

Be aware that my company has adopted the same course materials and approach. So this last reason can be seen as a shameless pitch. However, there is the topic of my reputation.

Questions and Answer

Q. Must I Switch to e4 RCP? 
A. Yes. If your code is based on Eclipse technology you must move on. 

Q. Do you need to switch today.
A. No, but do not dwell in old RCP. Be decisive and start planning the conversion process. Plan new projects to be developed in e4.

Q. Is the training really needed?
A. Only if you don't want to waste time.


Q. Is e4 stable enough to host my mission critical application today.
A. Today? No promises but it is getting there.

Q. What do you mean? Does it contain bugs!?!
A. That is a promise.

Q. Are there more questions?
A. And answers too. Check this.

Is it the Egg Laying Woolmilkpig?

Frankly, there is no framework that can match Eclipse RCP. The problem for me with other frameworks has always been the 80/20 rule. 80% possibilities and 20% struggle. Eclipse is programmed in and with Java. Anything is possible. 

But you tell me. I love your comments.


...