Making sense of e4

There was so much going on at EclipseCon last week that I have to admit my head is still spinning. I’m trying to get back to work, but my mind keeps turning to the people I met and the sessions I attended.

One area I really wanted to get into at EclipseCon was e4, which is the project that is attempting to redefine the Eclipse platform. The work being done is varied and fascinating, and I’ve been trying to figure out what it all means at a high-level. Well from what I’ve learned so far, the two main focuses of e4 are flexibility and simplicity.

Flexibility

The platform is becoming more flexible in so many ways, it would be hard to list them all. But here are a few examples:

  • Internal structure of workbench window is up to you. Use perspectives or not. Embed parts in other parts, etc.
  • Much stronger styling support using style sheets.
  • Ability to create widgets and parts using different toolkits and even different languages.

One thing is clear – e4 is going to drastically increase our options when developing RCP applications.

Simplicity

The platform is becoming simpler in that the platform framework is being broken down into smaller and more uniform APIs that are loosely coupled to each other. Examples of this are:

  • Increased focus on POJOs throughout the various APIs.
  • Decoupling of APIs through contexts and dependency injection.

I really do think that it will be easier to develop RCP applications after these changes are made. Hopefully it will make my job as an RCP trainer easier too!

The conflict between flexibility and simplicity

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

Sir Charles Anthony Richard Hoare

What’s interesting is that flexibility and simplicity are usually in conflict. In framework design, we usually trade flexibility for simplicity and vice-versa. So how will the e4 team pull this off?

The answer lies in the idea of insightful simplicity. There are many types of simplicity, and some are not at all useful to software developers. But insightful simplicity arises when a team has lived with and understands a domain so thoroughly that they start to see the problem space in an entirely new way. Insightful simplicity can result in architectures that are not only simpler but that dramatically increase flexibility, enabling developers to create entirely new types of applications.

Insightful simplicity usually arises only after an initial framework has been created and evolved for an extended period of time. Frameworks tend to expand and get more complex as new use cases are incorporated, but eventually there comes a point when a team starts to see how the entire thing can be collapsed and simplified. This is where we’re at with the Eclipse platform, and the e4 team is now taking this insight and turning it into a reality.

Personally, I can’t wait to see what going to happen when developers get a hold of this technology. It’s going to be amazing!

Advertisements

3 Responses to Making sense of e4

  1. Eric Rizzo says:

    This is the first description of e4 (including all the presentations at EclipseCon ’08 that I attended) that actually makes me interested in and hopeful for e4. It’s the first thing I’ve read that focuses in on the core principles behind e4 instead of the “Eclipse in the cloud” or “Hey, CSS for SWT is cool!” nonsense.
    Thanks, Patrick.

  2. Great summary Patrick! Leave it to an educator to boil things down so succinctly. 🙂

    We believe it’s extremely important that we increase the options for RCP developers. And hopefully bring forth some simplicity although as you say there’s always trade offs, and simplicity for one may not be simplicity for another.

    We of course highly value any input RCP experts such as yourself can provide in helping to drive the technology to ensure it’s real and vital, either through application to representative examples, prototyping of real world applications, or refinement of common requirements.

  3. Patrick says:

    Hi Kevin,

    Thanks for the feedback, and for your invitation to contribute. I definitely believe all RCP developers should be examining e4 and checking it against their use cases.

    I think a lot of developers have been a little intimidated by the wide variety of things going on, but hopefully more people will start looking at e4 as the pieces start coming together.

    — Patrick

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: