Eclipse 4: The Path of Least Resistence

Or, why the E4 API is better than the old one.

The 3.X API is fragmented from years of development, with technical dept, and too many mechanisms to do the same thing, call chaining to get at things, etc.  This is typical of any far reaching API; it's very difficult to anticipate what developers will need in the future.

This is what E4 came into being.  The goal:  make things simple, and hard things possible.

The E4 UI controlled by a model:

• Model is persistent and contains everything necessary to render the UI
• Model is the API; everything it can do, you can do
• Add listeners to any aspect of the model
• Dependency injection (DI) replaces listeners
• Registering the selection as a parameter to a method means that the method will be invoked every time that the selection changes.

The result is that E4 has little to no API, and as a result is extremely flexible.

A few other improvements:

• No internal APIs are accessible anymore (i.e., internal packages)
• Down casting is unnecessary

The evidence of how good Eclipse 4.2 is is that they were able to implement an Eclipse 3.8 layer to support backwards compatibility with very few changes to E4.

I am looking forward to being able to start using E4 for our applications.  There will be a lot of concepts that are difficult to grasp and effectively use at first, but the flexibility that it offers, especially in terms of being able customise the UI to support different work-flows, is amazing.