I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Eclipse SDK 4.0: A Platform For A New Wave Of Killer Apps?

08.04.2010
| 11171 views |
  • submit to reddit

Last week you may have noticed that Eclipse SDK 4.0 got an early adopter release, allowing developers to play around with the updated SDK to create their own rich client applications.  It's a bit different from the "traditional" Eclipse, introducing a model based user interface and CSS for application styling, as well as a services-oriented programming model. 

While the main focus of the release is to allow Eclipse projects and plugins to prepare for future releases, the following tutorial shows how to write applications in Eclipse 4.0. Tom Schindl has also produced a useful introduction. I will be kicking off my own tutorial into e4 in the next few weeks.

I asked Mike Wilson, Eclipse Project PMC Lead a bit more about the e4 release:

DZone: What is the difference between e4 and the core Eclipse stream?

Mike Wilson: e4 is the name of an incubator, not a development stream.

Ignoring source bundles, the difference between the Eclipse 3.6 SDK and 4.0 SDK is (only) a new version of the Workbench bundle, some new branding, and some new bundles to support the new workbench's implementation. The other 184 (assuming I counted correctly) bundles are common between the two versions.

Internally, the workbench code has been completely re-architected to provide a new CSS-based look and feel, on top of a fully modelled user-interface. The changes involved in building this have been so significant that we have labelled 4.0 as an "Early Adopter Release". The intent is for it to be used by those early adopters that want to test backwards compatibility and migrate their plug-ins and RCP applications. I expect Eclipse end users will generally adopt the next release, Eclipse 4.1.

DZone: Can I use any Eclipse based framework like EMF or GMF in e4?

Mike Wilson: Yes. If the framework makes direct use of internals from the 3.x workbench implementation, it will need to be updated to be API clean first, anything else should
work fine. The new workbench is actually built using EMF core.

DZone: How long will you keep parallel streams going?

Mike Wilson: As you can see from the previous answer, the differences between the streams are currently quite small. Depending on where innovation is happening, the delta could get larger but, in any case, the incremental cost of maintaining the existing 3.x stream is low. Really, the constraints that 3.x has (i.e. stability and backwards compatibility above anything else) mean that that we will be able to maintain it as long as the community needs it.

DZone: e4 seems ready for early adopters. What is the plan to mature it past incubation status?

Mike Wilson:
At the risk of sounding like a broken record, e4 is the name of an incubator, of the form which I believe the foundation is calling a "perpetual incubator". It is a sandbox to allow new innovations in the Eclipse platform to be created. It will exist as long as the community believes innovation at the platform level is important.

If you mean the Eclipse SDK 4.0 Early Adopter Release, that is *not* in incubation. It differs from any other SDK release only in that sweeping changes in the internals of the workbench may mean that those who consume it will see more visible bugs than in other recent releases. We fully expect to resolve those bugs to bring the quality up to the expected level by next year's Indigo release. Interim milestone builds should provide evidence of that. [Aside: Because we are aligning our 3.7 and 4.1 milestones, "M1" happens one week after 4.0 ships, so you likely won't see much difference for this first one.]

DZone: What is your favourite e4 feature?

Mike Wilson: My favourite feature is that we have found a way to make innovation possible at the platform level. The new community that has grown around the e4 Incubator is strong evidence that we all care that Eclipse has a future

DZone: What is the rationale behind the name?

Mike Wilson: "e4" just comes from "e" for Eclipse, and "4" to indicate that the goal is to build the "next major version" of Eclipse after "3.x". The Eclipse SDK 4.0 Early Adopter Release is built using technology from e4, and is the first release of the Eclipse SDK that is part of that new 4.x development stream.

Comments

Jacek Furmankiewicz replied on Wed, 2010/08/04 - 2:04pm

I just wish there was a way to write Eclipse RCP apps without the whole OSGi overhead, just as straight SWT/JFace apps. Plugins are great for a pluggable app like Eclipse, but for a typical business app with a static set of modules OSGI sure adds a ton of complexity for very little gain.

Tom Schindl replied on Wed, 2010/08/04 - 3:31pm in response to: Jacek Furmankiewicz

If you don't want to use the OSGi-Service stuff and write one small monolitic application the Eclipse 4.0 Application Platform is though not 100% possible but you get away with very few OSGi.

Yes need to create an Bundle-Project but afterwards you get a way without OSGi completely. All you do is to write your POJOs and edit the application model - no need to use extension points beside the one and only to define the product, multiple bundles, ... .

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.