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 ResourceNavigator.java in 3.6):

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

getViewSite().getActionBars().getStatusLineManager().setMessage(msg);

In e4 this should be:

@Inject
IStatusLineManager statusLine;
...
statusLine.setMessage(msg);

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 = i.next();
      IResource resource = null;
      if (o instanceof IResource) {
          resource = (IResource) o;
      } else {
          if (o instanceof IAdaptable) {
              resource = (IResource) ((IAdaptable) o)
                      .getAdapter(IResource.class);
          }
      }
      if (resource != null) {
          list.add(resource);
      }
  }
}
return new StructuredSelection(list);

I'm not sure how we handle multi-selection in e4, but this should be something
like:

 @Inject
public void setSelection(@Named("selection") List<IResource> selection) {
selectedResources = selection;
}

3) I want to associate a help context with my control

    getSite().getWorkbenchWindow().getWorkbench().getHelpSystem().setHelp(
      viewer.getControl(), getHelpContextId());

In e4 this should be something like:

@Inject
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.