We're getting closer to the 0.9 release of e4, a major milestone in the future of Eclipse, and maybe all desktop applications. In this article, I'd like to give a summary of what e4 is all about.
A Reason For Change
Mike Wilson has covered e4 in his latest blog post, where he lists the important questions that have brought us to e4. Those questions are:
- Does Eclipse have a future on the desktop?
- What would an ideal Eclipse platform look like?
Presentation is an obvious point - we don't want clunky looking applications, we never did. There's no doubt that Flash applications can look great, we just want do be able to develop our apps to look flashy.
For any technology to have a future now, ease of use is the big thing. The learning curve has to be managable, so that developers new to Eclipse can write their first application quickly, get excited by the technology and become part of the community.
When you ask these question about Eclipse at the moment, I think you'll find that it takes new developers quite some time to get up to speed. It can be complicated, but once you start learning about Eclipse things just start falling into place. Maybe we need to lower the complexity for entry.
I'd strongly recommend reading that article in full, it gives a great background to the project.
What Is e4?
You'll find all the answers you need in the e4 Technical Overview White Paper.
The most useful definition is that e4 is a cluster of related technologies for building extensible component-based applications. Rather than a wholesale replacement of the Eclipse platform, e4 brings a new set of technologies into the existing Eclipse platform that make Eclipse components easier to write, more configurable by application developers and integrators, and easier to reuse in diverse runtime environments.
My favourite aspect of e4 is the reuse in diverse environments part, really tackling the issue of write-once, run-anywhere. For example, you can cross compile from SWT to Flash. Using CSS the user interface can be styled independently to the application code. The programming model in e4, just like the 3.x stream, is based on OSGi. The GUI is represented as an EMF model, so you can extend or modify this model to suit your own application's needs. There's a whole lot more that you can find out about e4 in that whitepaper.
Fitting into e4
While e4 will do it's best to be backward compatible with the 3.x stream, there's a chance that your plugins won't work on the platform. And this is one of the key points for me - if you think that you'll want to take advantage of e4, then you should get involved in the development. Whether this is just listening in on the mailing list, developing, or (and this is probably most important for e4 adopters) testing your plug-ins on e4.
And don't worry if you're still on the 3.x stream. This will be continuing as normal in parallel as long as people need/use it. Sounds like a good deal to me.