Is e4 a lemon?

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,

  • Posted at 05:59, 2010-02-05

    Hi Elias,
    Thank you for keeping us on our toes! 😉
    I responded here:

  • Posted at 06:34, 2010-02-05

    Hi Elias,

    you wrote: “It is not obvious what annotations are available at any given point (@Inject, @PreDestroy, etc).”

    I agree. I think it is important that together with DI, good documentation and tooling helps the developer to easily find out which things can be injected in a given context.

  • Tom Seidel
    Posted at 11:05, 2010-02-05

    Hi Elias,

    >makes it very hard for beginners to figure out how to write classes
    Agree. I thought exactly the same while I tried to build a simple e4 app. But I’m pretty sure that many people who uses Eclipse for several years (like you) will have their “problems” 🙂 It would be interesting to see how someone who never used Eclipse 3.x would start writing e4 applications.

    Your point regarding annotions, I think the use of annotations instead of interfaces/abstract classes is a matter of taste, I’m sure if there is better tooling avialable it becomes easier to start writing code. Some food for thought is the Code Recommendations project which was introduced at an Eclipse DemoCamp, see – Very interesting approach…

    The download size for the SDK is not relevant, relevant is the required footprint for my e4 based application.

    Killer-features: That depends on your expectations. I don’t know what you understand under “killer-feature” but from my POV e4 should _enable_ adopters to build killer features. And indeed this seems to become easier.


  • Posted at 11:09, 2010-02-05

    Contextual information on where you can use an annotation, and providing some kind of feedback on semantic interactions between annotations is really important for people new to any particular collection of annotation libraries. As part of the JAX-WS project, we’ve constructed a extensible annotation framework that provides live feedback of valid annotations in a separate view, as well as an extension-point driven way to plug in validation logic. You can supply extensions that will check the JDT model, query the annotations and provide info/warn/error markers if you compute that there are clashes or potential weirdosities. We need this because JAX-WS is chock fulla annotations and uses JAXB, which is even more chock fulla annotations. It’s a true “plague of snails”.

  • Posted at 14:11, 2010-02-05

    DI is really a step backward for me. I can see the advantages easily, but I also see one main problem that will hurt our users for a long time: You cannot know which values are available – via injection – until run-time. (side comment: isn’t this why we want to use languages like Java instead of JavaScript in larger project? The predictability?)

    In 3.x, the basic rule is: if you can reach it (via Java method calls), then you can use it.

    In 4.0, there are no such rule. The name might be present in IServiceConstants or you might know the interface name, but there are no knowing whether the context will contain a corresponding value.

    In 3.x, we more or less had the same problem with the IServiceLocator, as there never seemed to be any documentation for the available services, and I can say I have tried to explain this in many a Eclipse RCP training class. Failing…

    Lets not repeat that again.

  • ilx
    Posted at 11:14, 2010-02-06

    I don’t like the idea of BIG rewrites.

    There are some things I would like to see right now in 3.x:
    – css theming – IIRC this can be backported!
    – declarative UI – I would really like to declare UI on the server side and push it to the client (it is possible to do this today as demonstrated by Ekkes RedView and CDO)
    – ability to redefine eclipse perspective (related to modeled/declarative UI)
    – dependency injection – I used equinox aspects with spring-dm to achieve this – it’s FAR easier to do this and write simple junit tests than relying on service locators, factories and other monsters
    – support for MS Ribbon – yes, people will argue it’s horrible and I do find it horrible when it’s my word in question, but it looks really god when I look at the clutter on my eclipse toolbar

  • André
    Posted at 13:53, 2010-02-06

    Completely agree with your POV!!!

  • Elias Volanakis
    Posted at 18:23, 2010-02-08

    Thanks for the comments. I think we agree that DI without good documentation, interfaces, tooling makes things harder.

    @Boris: I will reply over at your blog.

    @ilx: I would like the ribbon (native or emulated) too. The native ribbon is discussed in these bugs: 298481, 298481. I’m also working on an emulated ribbon with ide integration in my spare time: (screencast, github)

  • Shawn Spiars
    Posted at 21:34, 2010-02-15

    Elias – Thanks for sharing what many of us are thinking about e4. Simplicity and ease-of-development
    is way more important than a new killer feature. Eclipse plug-in development is already way to
    confusing for the average developer. Of course, you guys are not average developers, hence the
    problem trying to design user-friendly, intuitive tools.