Let’s assume for the moment, that in an alternate reality I can travel back in time to 2008. Once there, I meet a bright bunch of people that work on something called e5 (executive summary.odp). My summary:

“the runtime platform that is simple and appealing to _____ application developers”

Here’s what I would say to them:

e5 should take risks

When I became interested in Eclipse it was cool and disruptive. A real game changer. It is now the established tooling platform and understandably locked into perpetual refinement mode (Entrenched Player’s Dilemma). Make sure that e5 is equally game changing. Otherwise we are setting ourselves up to be disrupted.

At the EclipseCon 2008 we committed a “strategic sin”. We agreed that e4 would be compatible with 3.x. This limited the potential for e4 by forcing it to be something that is “in the box” vs. “outside the box”.

(taken from Death by risk-aversion by Kathy Sierra)

For e5 to be successful it needs to take risks. I don’t think that we need a better tooling platform. We already have a very good one with 3.x. And it’s still improving and not going away. Instead we need a runtime that provides something unique and remarkable. It must kick-ass in a new way.

e5 needs a driver

If you try to be everything to everybody, you will at best be mediocre at everything. e5 should be laser focused on being the best runtime for ___________ developers.

People tend to avoid specialization. It is perceived as a risk. However, if you ask a marketing person he / she will tell you that specialization is good. It’s your way to get noticed. It’s your foot in the door. You build a niche, become unbeatable and expand. Eclipse 3.x first became the tooling platform of choice, then client platform of choice for Java devs, then the modeling technology of choice for Java devs.

Unfortunately e4 lacks a driver that would help it specialize and focus. A driver, like the JDT was for the Platform. As far as I know, there is no major product build on top of e4. I believe that the current e4 (Feb 2010) is not yet appealing enough for web development or client development. It will not lure web-side Java developers away from Spring / J2EE / GWT. Or client-side Java developers away from RCP. Or Javascript folks away from jQuery / Prototype / Dojo. Or Rubyists away from Rails.

It is hard to pick the right driver. I don’t want to attempt providing an answer and limit your thinking. But feel free to share your thoughts in the comments.

e5 must be easy to learn & master

If you believe Eclipse 3.x is easy to get into, attend a beginner’s training. You will see how experienced Java developers struggle with the learning curve. And it’s not becoming easier with e4.

That is a problem, because it limits the mass appeal of Eclipse as a runtime solution. If you think it is a popular runtime, go to a Java User Group and see how few of the people who use Eclipse have written a plug-in for it.

It is in our human nature, that we tend to take the path that has the least resistance (read: easy) not the path that offers the most rewards (read: complex technology).

For e5 to be broadly successful it must kick-ass AND be easy to learn & master.

Looking forward to your comments,
Elias.

Tags: e4

Image credit: So gesehen@flicker, CC BY-SA 2.0.

I have been playing around with e4 (M3+Integration) today and so far I’m not impressed. I’m keeping an open mind, and may change my opinion at a later time.

At the moment however,  I would dare to say that e4 might be the “Windows Vista” moment for Eclipse. High hopes, but at the end of the day not groundbreaking enough to be interesting for a wide audience of developers (=regular java devs, web devs)

There are some things I like a lot and would like to see in 3.x, such as:

• CSS theming
• trident animations
• getting rid of the *Advisors

The biggest drawbacks in my opinion:

#1  NOT simpler,  just different

From my POV app development is still too complex for the avarage developer.  Here is why:

• Using dependency injection via annotations instead of having interfaces / abstract classes makes it very hard for beginners to figure out how to write classes. It is not obvious what annotations are available at any given point (@Inject, @PreDestroy, etc). The type hierarchy does not help for finding similar implementations – since there is no hierarchy
• The e4 workbench designer for the workbench model (.e4xmi) is nice, but unstable (failed to load my simple example). Editing the .e4xmi by hand or a tree-like emf editor is cryptic and less user friendly than the plugin.xml editor
• The plugin.xml is still necessary. So with the .e4xmi file we now have two .xml files that are relevant. I would like to see just one or none.
• Still too many technologies to master: Extension Points, OSGi, Workbench Model, EMF, Annotations, SWT, JFace.

“Simplify the programming model” is stated as e4’s first objective (e4-summary.odp), but  I don’t think this is true at present.

#2 Still big and intimidating

I often hear the Eclipse is big, bulky and intimidating. The Eclipse e4 download packs 230 MB and all the UI clutter we are used to – but many newbies find confusing.

#3 No killer feature

If a customer asked me about migrating to e4 for a product that launches in Q4 2010, I couldn’t really recommend it. At this point I don’t see any “must have“ features yet — especially for the folks that have 3.x apps up and running.

This is bad and a bit of a catch-22 situation:

• Without some “must have”  features people are going to stay with what they already know (3.x) instead taking the risk of using something new
• The longer people wait to use e4 the longer it will take to reach critical mass and a high level of maturity (i.e. most bugs found)

Looking forward to your opinions – especially if you disagree.

Kind regards,
Elias.

Tags: e4

We’re all looking forward to talk about EclipseRT, Equinox and RAP at the DemoCamps around the world. In case you want to catch us and talk about Eclipse and related topics, just join one of the DemoCamps near you. Besides many other interesting talks, we’ll mostly cover EclipseRT, RAP and p2.

Ottawa, ON, Canada – November 24 – Jeff McAffer (EclipseRT)
Braunschweig/Hanover, Germany – November 25 – Benjamin Muskalla (RAP)
Stuttgart, Germany – November 26 – Jordi Boehme Lopez (p2)
Kaiserslautern, Germany – November 26 – Holger Staudacher (RAP)
Frankfurt, Germany – November 26 – Benjamin Muskalla (EclipseRT,RAP)
Vienna, Austria – November 30 – Chris Anisczcyk and Jeff McAffer (RAP,EclipseRT)
Karlsruhe, Germany – December 3 – Markus Knauer, Benjamin Muskalla (EclipseRT)
Hamburg, Germany – December 4 – Jochen Krause (RAP)

I’m really looking forward to see you at the DemoCamps, as always it tends to be a lot of fun!

Tags: democamp, e4, eclipse rap, eclipseRT, equinox, helios, rap, Single Sourcing, talks

Today, the Eclipse e4 project had its first 1.0 milestone release.

This is the beginning towards sprinting for the 1.0 final release.

The big new and noteworthy in this milestone is support for remote debugging of JavaScript and in particular e4 JavaScript bundles. The support is currently restricted to Mozilla Rhino, however in true Eclipse fashion, the JavaScript debug model and extension models are in place to allow supporting other JavaScript runtimes.

If you’re interested in Eclipse e4, here’s some resources:

• e4 whitepaper
• Mike Wilson’s blog post on the future of Eclipse
• e4 wiki
• e4 webinars

Enjoy and please consider contributing to the e4 effort!

Tags: e4, helios, javascript, milestone

I recently blogged about the OSGi EventAdmin service and got some good feedback. I like to inform people of some more things that came to light about EventAdmin. First, I added a template in PDE for the OSGi EventAdmin service that will make its debut in Eclipse 3.6 M3:

It basically uses OSGi Declarative Services to register an EventHandler that listens for the bundle started event topic by default:

org/osgi/framework/BundleEvent/STARTED

Hopefully this should make it easier for people to get started with OSGi EventAdmin.

Second, Scott Lewis from the Eclipse Communications Framework (ECF) team has a distributed version of the OSGi EventAdmin service implemented. If you want to get at the code, check out the ECF wiki.

Finally, the Eclipse e4 project (the next generation of the Eclipse platform) is somewhat interested in the OSGi EventAdmin service. There’s been discussion on a bug around the general problem of model eventing and how to avoid the ‘listener hell’ problem we had with the old platform.

Tags: e4, ecf, OSGi

I recently had a few people come to me to chat about the OSGi EventAdmin service. For those who are curious, the EventAdmin service is part of the OSGi Compendium Specification and allows you to publish and listen to events via a pub-sub system. I’ll try to do a quick write up on how to actually use the service. As with any OSGi service, the first and foremost thing you need to do is acquire the EventAdmin service. There are many ways to do this, but I prefer to use Declarative Services these days. This is what a sample component definition would look like:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" 
   immediate="true"
   name="org.eclipse.example">
<implementation class= "org.eclipse.example.MyClass"/>
<reference bind="setEventAdmin" interface="org.osgi.service.event.EventAdmin"/>
</scr:component>

Once we acquire the EventAdmin service, there are really two things you can do: publish and listen for events.

Publishing Events

To publish events, you need to pick a name for your topic. For example purposes, let’s pretend we wanted to publish information about memory events. A good topic name for this would be something like:

org/eclipse/equinox/events/MemoryEvent/{NORMAL,SERIOUS,CRITICAL}

If we wanted to publish a critical memory event, we have to create an Event object and publish it using EventAdmin:

...
Event event = new Event("org/eclipse/equinox/events/MemoryEvent/CRITICAL", null);
eventAdmin.postEvent(event);

It’s important to note that there are two ways of sending events using EventAdmin. This depends whether you want your event to be sent in a asynchronous our synchronous fashion. In the example above, we used the postEvent(...) method in EventAdmin which sends events in an asynchronous fashion. To send events in a synchronous fashion, EventAdmin exposes the sendEvent(...) method so we could simply change our code to send event synchronously:

...
Event event = new Event("org/eclipse/equinox/events/MemoryEvent/CRITICAL", null);
eventAdmin.sendEvent(event);

An additional thing to note is that you can send additional properties with your events as the Event object takes an optional Map parameter in its constructor.

Listening for Events

From the consumer side of things, we’re interested in handling the memory events. To do this, we need to register an EventHandler, let’s call it a MemoryEventHandler in this case:

public class MemoryEventHandler implements EventHandler {
 
	public void handleEvent(Event event) {
		// TODO panic... handle memory event
	}
}

Next, we need to register our MemoryEventHandler with the service registry with the proper EventAdmin topic name. There are many ways to do this, but for the variety purposes, let’s do it the traditional way in a bundle activator via a BundleContext reference:

...
EventHandler handler = new MemoryEventHandler();
properties = new Hashtable<String, String>();
properties(
   EventConstants.EVENT_TOPIC, 
   "org/eclipse/equinox/events/MemoryEvent/CRITICAL");		
context.registerService(EventHandler.class.getName(), handler, properties);

The important part of the service registration involves topic you’re interested via the EventConstants.EVENT_TOPIC constant. In the example above, we were interested in critical memory events so we used the proper topic:

org/eclipse/equinox/events/MemoryEvent/CRITICAL

If we were interested in all memory events, EventAdmin supports wildcard matching on topics so we could do this:

org/eclipse/equinox/events/MemoryEvent/*

EventAdmin also supports filtering via the EventConstants.EVENT_FILTER constant.

For the curious, the example above could have easily been done using DS:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" 
   name="org.eclipse.example.memoryHandler">
<implementation class="org.eclipse.example.MemoryEventHandler"/>
<service> 
 <provide interface="org.osgi.service.event.EventHandler"/>
</service>
 <property name=”event.topics” value=”org/eclipse/equinox/events/MemoryEvent/CRITICAL” />
</scr:component>

That’s all it takes to listen for events!

EventAdmin in Eclipse

Cool, now that you know more about EventAdmin… how about using it in your Eclipse RCP applications? Well, I have good news as Equinox has a great implementation of EventAdmin available. Furthermore, as of Eclipse 3.6 M2, EventAdmin will ship part of the Eclipse SDK. If you’re not building on top of Eclipse 3.6 yet, you can simply grab the event admin implementation from the Equinox SDK downloads page.

Note: The example I described in this blog is something someone proposed be included within Eclipse.

Tags: e4, OSGi

With e4 0.9 out in the wild, we should think again about the goals e4 tries to provide. One of them was to reduce the gap between Desktop and Web – not only speaking of reusing widgets but also to enable the platform handle multi-user scenarios. While the core e4 team concentrated on eliminating bad smells like singletons, the RAP team worked on better support for single sourcing applications in general. With an experimental version of RAP which includes some features not yet in the current release, we were able to run the demo out of the box including the whole underlying infrastructure like the modeled workbench – without touching the e4 code.

If you take a look at the RAP Demos page you’ll find the e4 contacts demo running on RAP. If you want to try it out yourself or even help to contribute to this effort, take a look this wiki page. In case you’re interested what you can do with e4, be sure to participate in the e4 webinars.This week, there will be Part 2 with topics like RAP, the Compatibility layer and the flexible resources model. Looking at the questions that came up in the last RAP webinar and the first part of the E4 webinar, people seem to be very interested how e4 and RAP play together. I’ll try to answer the open questions during the webinar this week. Looking forward to a great event.

Tags: databinding, e4, eclipse rap, Single Sourcing, swt

Last week, the Eclipse e4 project had its alpha release.

What’s e4?

It’s simply the next generation of the Eclipse platform. The Eclipse platform team has learned a lot of lessons since the Eclipse project started and it’s time to experiment and innovate. There’s also a desire to involve more people at the platform level.

To get a better idea of where e4 is going, here’s some resources:

• e4 whitepaper
• e4 New and Noteworthy
• Mike Wilson’s blog post on the future of Eclipse
• Register for e4 webinars
• e4 wiki

If you’re interested in the project or the future of Eclipse, the e4 team would love to hear from you.

The first general release of e4 is expected in 2010.

Tags: e4

We try hard to enable a “sexy” look and feel for Rich Ajax Platform (RAP) applications. However, without rounded borders and gradients you can hardly create a website that look modern. Take this dialog as an example:

It looks so much better with rounded borders on Shell, Control and with these Button gradients:

The latter screenshot has been taken from the current RAP development stream. These features were challenging to implement but we eventually came up with a solution. The interesting part is that it’s not image based. Instead of creating a bunch of images (one for every corner and side), all you have to do is define your border radius in the CSS style sheet.

How does it work?

We are using vector graphics (SVG/VML) in the browser. This works with all browsers supported by RAP (FF2+, IE6+, Safari 3.1+, etc.) without any add-ons. Check it out on our examples demo.

And how does the CSS look like? For gradients we followed the CSS syntax implemented by Webkit-based browsers as Safari and Chrome. Besides a start color and an end color, you can also define any number of intermediate steps. We only support vertical linear gradients in the first version, but this will change. By the way, we proposed to use the same syntax for styling in e4.

  background-image: gradient(
    linear, left top, left bottom,
    from( #ffffff ),
    color-stop( 48%, #f0f0f0 ),
    color-stop( 52%, #e0e0e0 ),
    to( #cccccc )
  );

For rounded borders we followed the CSS 3 syntax. You can set rounded borders using the new border-radius property (even a different radius for every corner is possible).

  border: 2px solid #005092;
  border-radius: 6px;

Both features are available in the RAP CVS and will be included in the 1.3 M1 release shipped in August.

Enjoy!

Tags: e4, eclipse rap, rap, styling, swt, theming

e4 0.9M5 is now available for download.  One of the things that excites me about this work is the web based form editors that Boris Bokowski has been working on.  The form editors have always tried to mimic a web look and feel, but now they are using real web technology.

The e4 team has even integrated these editors with the workbench.

For a complete list of features, checkout the e4 New and Noteworthy.

Tags: e4