Thursday, February 04, 2010

Can we turn e4 into an orange?

Let me write a quick response to Elias' thought-provoking post. I hope there will be other (and not so quick) responses as well - it is important to step back every now and then to assess whether we are going in the right direction. But for now, I didn't want to let the issues he raises without an answer from the e4 team. The question for me is, how can we turn e4 into a juicy and sweet lemon? ;-)

Killer feature: I fully agree that support for styling and skinning is not going to be enough of a killer feature to convince everybody that it is worth stepping up to e4. What could be other killer features? To be honest, I am not sure. I would be interested in hearing opinions on this - please leave comments!

Download size: The 230 MB are easy to explain - this download includes the 3.x Eclipse SDK (167 MB), the EMF SDK (27 MB), some parts of WTP, GEF, and other bits and pieces. If you just look at the e4 bundles, they amount to just over 2 MB. The dependencies of the core e4 bundles (a subset of those 2 MB) are SWT, JFace, Equinox, and the EMF core runtime. It could always be smaller, but the 230 MB are just the wrong number to look at. Unless you are interested in the footprint of e4 + compatibility layer + everything from the current Eclipse SDK, but clearly it is not the long-term goal of e4 to always ship with everything from 3.x.

Different: This takes a little longer to explain, but luckily a good response already existed, in the form of John Arthorne's argumentation from bug 300099 comment 4 (I made minor adjustments to make it fit better into this blog post):

The purpose of injection was to make it easier to obtain services in the general case, as well as to decouple of service user from knowing or caring about who provided the service. I'll offer a couple of examples that I've taken from the existing 3.x code (all from the current in 3.6):

1) I want to print a message on the status line. In 3.x this is:


In e4 this should be:

IStatusLineManager statusLine;

2) I want to get the selected resources:
 ArrayList list = new ArrayList();
if (selection instanceof IStructuredSelection) {
IStructuredSelection ssel = (IStructuredSelection) selection;
for (Iterator i = ssel.iterator(); i.hasNext();) {
Object o =;
IResource resource = null;
if (o instanceof IResource) {
resource = (IResource) o;
} else {
if (o instanceof IAdaptable) {
resource = (IResource) ((IAdaptable) o)
if (resource != null) {
return new StructuredSelection(list);
I'm not sure how we handle multi-selection in e4, but this should be something

public void setSelection(@Named("selection") List<IResource> selection) {
selectedResources = selection;
3) I want to associate a help context with my control
viewer.getControl(), getHelpContextId());
In e4 this should be something like:

IWorkbenchHelpSystem helpSystem;
helpSystem.setHelp(viewer.getControl(), getHelpContextId());

The end result is simpler code, but it also removes a mass of assumptions that
the client previously had to make, about what their containment structure
looked like and where specific services came from. I think we sometimes take
for granted how difficult it can be for clients in 3.x to figure out where to
get particular service from.

Having said all that, we have probably gone too far down the
"non-specification" route in e4. I think it is essential that we provide
interfaces containing specification of things clients must implement (e.g., you
need a doSave() method for parts that are to be used as editors). We can make
the interface optional if we want, but there has to be somewhere where we
specify the behavior expected/required for clients. To me this specification of
expected behavior for clients is orthogonal to service injection so I hope that
we can have both.


Philipp Kursawe said...

Why would you have to annotate in the first place? If e4 is already using reflection, then it could just as easily pick of the field that have the expected type for injection.

Other than that I would like to see all the IListener* interfaces add/remove code go away and use OSGi EventAdmin for primitive notifications and the use of the White-Board-Pattern in other cases.

Recently I wanted my view to respond to preference changes directly. I would just register my view as IPreferenceChangeLister with a service property "qualifier" and an extender would pick that service up and notify it about changes of properties. Yet, it could be even simpler. Have a convention how fields or setter methods have to be named to corrospond to properties and the extender could set the fields directly.

Color backgroundColour;

void setForegroundColour(Color color) { doUIupdate(color); }

The extender would get a property change event for the "myplugin.backgroundColour" preference and sets the field directly. In thte "myplugin.foregroundColour" it sees that there is a setter method available and calls this instead.

Of course all such behaviour would have to be documented somewhere.

What do you think about the need of annotations in e4 for injection?

Anonymous said...

Hi Boris,

in my experience with 3.x RCP, the lack of customizing the look and feel (in terms of implementing a given visual design) in some cases has been a "killer feature" for not using RCP. I hope that the new styling mechanism will help here and turns into a killer feature in the positive meaning of the phrase!

Boris Bokowski said...

@Philipp - with the annotations, we are for the most part just implementing the JSR-330 spec for dependency injection, i.e. following a pattern that is already used by frameworks like Google Guice. Kent Beck just posted something which I take as confirmation of our approach of using annotations vs. just naming conventions: "I’m a big fan of declarative expression in programming languages. Annotations are superior to convention (like naming all test methods “test…”) for declaring intent because they can be checked by the compiler. The addition of parameters to annotations makes them even more expressive."

Lars Vogel said...

I agree with Kai. Styling is one possible killer feature. I personally also like that with e4 you get rid of a lot of boilerplate code; all the annoying adviser classes are gone.

On the bad side of e4 the tooling support is not yet up with the currently PDE tooling in 3.X.

Also there is not yet enough documentation for new people to try out e4 but we are working on that one...

pascal leclercq said...

IMHO, a killer feature that e4 should provide is the ability to developp a UI one for good and the deploy on ay kind of latform including Web and Fat client. This way you get rid of the argument : I don't want a fat client since some people won't have the possibility to access the app.
Of course switching from web to fat client should be as easy as possible and in any case e4 should provide "best ractices" to explain how It should be done.
BTW dependency injection is a really great feature.

Pascal said...

We already have a killer feature, Speed! I found the contact demo to be very fast to come up compared to the Mail App.

At this point I think it would be better to focus on e4 to just be a runtime technology and not a replacement for the IDE since there is not enough novelty there.

Simon Chemouil said...

Unfortunately, I have no time to write a much about what I believe e4 should aim for. I admit I did not go deep into e4 but I've looked at it a few times. I know some of the items on the list are already scheduled but I'm just saying a few points I'd like to see anyway:

- Make e4 more RCP-friendly: IDE dependencies/orientations (like the way resources are handled) should disappear
- In fact, e4 should be first and foremost a RCP (or RCP+RAP singlesourcing) framework for applications in Java that leverages the power of OSGi and component-oriented architecture
- More "pure OSGi" equivalents (ie, provide ways to use Equinox Registry AND OSGi services for most features, with no hard coupling on Eclipse Extensions, so we can use Eclipse components without requiring the Equinox Registry bundle and learn another extension model)

- Deprecate old stuff (IAction, etc), singletons, ...

- Real support for alternative JVM languages (that means light wrappers for some mappings, making sure that the patterns used fit well with other languages, etc). I believe Scala and Clojure (with Groovy as a distant third) are the most important languages to support if Eclipse is to keep its technological edge, because Scala & Clojure's emphasis on immutable data structures provides food for thoughts that could be useful in E4's design.

For Eclipse IDE:
- JDT is its flagship, it is great but it can be tremendously improved, and it needs to reflect the status of the current Java ecosystem
- That means splitting JDT into a JVM-support component and another Java-the-language dedicated component
- Letting other providers make their language plugins based on the JVM-support component (look at what they do with Equinox Aspects/Weaving, unfortunately this is just a short term solution that does not fit well with the component model and shows that JDT needs more modularity)
- PDE should be renamed to ODE (OSGi Development Environment), because BDE (Bundle*) doesn't sound so good, and OSGi is not going away anyway. PDE should be plugged into the JVM-support component rather than the Java-the-language component, to support more languages out of the box. It should be in the default Eclipse E4 IDE and should be the standard way of making a new Java project...

- Less "NIH" syndrome: use other F/OSS projects that work well at what they do: Maven, Tycho, Hudson. I want to see those more tightly integrated with Eclipse. I know Eclipse took what was there when it started, but now projects like Maven are mature and used enough that it M2Eclipse should be the default building system...

I have zero interest in CSS/theming Eclipse, I am developing industrial RCP apps for a huge avionics company. I like Eclipse because of its component model (and the fact that it's OSGi) and the quantity of quality components that can be plugged into it. So far my concerns are related to shortcomings I feel with 3.x and with a wish to see Eclipse continue to evolve further towards technical excellency.

Stephan Zehrer said...

For me the EMF base Model components including TM are the killer part of E4. A bit more documentation would be nice. The approach at the end to generate a application increase in point of view the development time.
And with EMF you get many stuff for free.
IOC rsp. DJ is what I prefer cause many developers know i from Spring or Guice (even Maven will use this now).
What I am not sure about is XWT, maybe I didn't understand all details yet.

Mickael Istria said...

Like Kai and Lars, I strongly believe that styling is a killer feature. Indeed this should reduce cost of UI customization, and would make possible to delegate the look'n'feel of an RCP application to a designer. Moreover, ability to change dynamically with a few clicks the CSS o the application and its styling is very interesting because it will allow designers to work without the help of developers.

This is something we are all dreaming about in our team, and this is the killer feature that will make us migrate our product to e4 as soon as possible.

Philipp Kursawe said...

Simon, I agree with you. Although I do not understand your comments about JVM support (I am using only the standard JVM). But I also would like to have PDE finally renamed. The notion of "plugins" should go everywhere and "bundle" should be used. ODE/BDE that's certainly up for discussion.

A more OSGi centric approach inside e4 would be nice. Combined with dependency injection that is a good technology. I am happy that 3.6 finally exports the IWorkbench service, so that I can create DS that reference it. A better use of the white-board-pattern would also increase simplicity of RCP development. No more ListenerList management. Let the OSGi service registry do that for you.

About moving extensions to OSGi that has been discussed before and since extensions are different than OSGi services (especially lazy loadding, providing no code at all, just meta information) this system should stay in place as it is.

Lars Vogel said...
This comment has been removed by the author.
Lars Vogel said...

@Philipp I personally believe we should rename to "plugins" (currently it is plug-ins). Plugin is a term widely used, e.g. firefox.

This term is well understood in the IT world. Basically everyone knows what you mean if you say "I develop a plugin for ...". Bundle may be the right technical term but is not well understood outside the OSGi world.

konberg said...

Styling doesn't seem like a killer feature. I'm supporting a large number of Eclipse users and if I were to ask them what they needed to make their job easier, "CSS styling" wouldn't come anyplace near the top. They need a simpler, more responsive, UI with more powerful features.

Here's the killer feature I would like to see: the one that I believe would bring emacs and vi users in droves:

Never prevent a user from typing in an editor. Ever.

Anonymous said...

Hi Boris,

thanks for taking the time to reply to my post. I think we are in agreement in 2 out of 3 points:

- There is some work needed to make DI easier to work with:

> I think it is essential that we provide interfaces
> containing specification of things clients must
> implement

- CSS by itself is not the killer feature.

It is without doubt a nice feature, but the problem is that it is still limited by the things SWT and/or the native widget's cannot do. A few examples: setting background color of a Menu or Button. Setting the foreground / background of table headers. Placing a SWT.BAR Menu at a location other than the top of the Shell.

Kind regards,