@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)

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

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.

>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 http://www.stg.tu-darmstadt.de/research/core/overview/home/index.en.jsp – 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.

Tom

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.