E4/Pervasive Themes

At the E4/Summit, some pervasive themes that may affect all of E4 have been identified:

• E4/Architectural Foundations
• E4/Eclipse Application Model

This page is to collect ideas and start drafting architecture early in areas that would be hard to change after the fact. We'll also need to find out how to best communicate about these pervasive themes, and hopefully find leaders.

Reducing Bloat

• Apparently, reducing bloat requires unifying things that used to be done separately, which makes it a prime candidate for a Pervasive Theme.
• When Eclipse as a whole is perceived as bloated, what can the core Platform do to avoid bloat in the whole of its extenders? - Fostering lazy loading and instantiation, good UI concepts, ...
• Where do we see bloat that could be avoided in the core Platform?
  • See Boris' Accidental Complexity Blog
  • Code / Logical Layer
    • UI Code Duplication - See Boris' Blog - use languages for declarative UI
    • API Bloat: Clearly mark a small set of core APIs as recommended, and deprecate (older) alternative ways of doing the same. For instance: Actions vs. Commands and menus, IPreferenceService vs. getPluginPreferences(). Related to E4/Eclipse Application Model.
      • Single Responsibility Principal (SRP) - Dave Carver's Blog
      • API Design by Joshua Bloch
    • Missing Mechanism Bloat: The Too Many Listeners Problem, for instance, is a result of not having a proper mechanism in place. Boilerplate code like for Extension trackers seems an indication that some mechanism is missing.
    • API vs Non-API: See Gunnar's E-Mail and Kevin's response - Use the experience collected over the years to come up with good design decisions for allowing re-use vs. lock-in
    • Componentization: Get rid of stuff rarely used from the core framework where possible. Related to Nexus Project for mix-and-match of extending components on a more fine-granular level. P2 might help.
    • Constant Code Hygiene: See John's E-Mail about code weeding, cap and trade
  • UI / Workflow Complexity
    • Too many Preference pages. See Mylyn/UI_Design#Idioms. What about going like Firefox, with config files for the advanced stuff and fewer Preferences for the stuff that's important for users?
    • The Problem of Perspective Multiplicity - referencing Netbeans and Common Navigator
    • See also the Eclipse to Textmate blog
  • Performance / Size / Physical Layer
    • NLS Strings and Images - See Martin's Mail. Combine into a database at install-time, use int for referencing at runtime. Requires new API for accessing such Resources.
    • Duplication of Strings at Runtime - See Markus' Blog. Memory Analyzer finds 1988 dups of "id" due to extension registry. StringPool vs intern()? - See John's E-mail. Use Tools like MAT to check!

Listeners

Too Many Listeners

• Having a large number of listeners adds complexity and bloat to our API
• Can we agree on a common listener model? Some candidates are
  • Boris' Blog
  • Databinding Observables
  • EMF eObject (Drawback: Every Observable needs to extend eObjectImpl, no possibility for mix-in)
  • OSGi/Equinox EventAdmin
  • Other hand-written infrastructure?
  • Anything else?

Too Many Events

• We have "event storm" problems where a single mouse click or API call can result in a cascading series of events. For example clicking an editor tab can result in thousands of events being sent. This makes the UI sluggish and adds performance cost to seemingly innocuous API calls.
• What can we do to reduce the number of events occurring?
  • Asynchronous events would allow clipping of redundant events in the queue
  • Listener APIs that encourage/require the client to give details about what kind of events they are interested in allow for optimization of event delivery. I.e., instead of addPartListener(Listener), have addPartListener(Listener, Part, int eventTypes) that allow the event bus to filter out uninteresting events before they are sent.
  • Use batching mechanisms where appropriate to avoid sending events about uninteresting intermediate state

Becoming More Asynchronous

• Being Asynchronous is not just a matter of adding callbacks. Here's some questions to solve:
  • How to debug a program that doesn't exhibit synchronous flow of operation? It needs to be easy to navigate from an API Call into the callback in order to set a breakpoint there.
  • How to perform Exception Handling? Callbacks will be executed in arbitrary Threads determined by the Framework. Clients may need to register exception handlers in order to react to exceptions in client code properly.
  • Logging and Tracing. With the logical flow of operation in a component split into multiple separate API Calls / Callbacks, it gets hard to trace overall program execution. An "overall" tracer that takes all requests into account might be needed in addition to trace filtering for individual components or individual requests only.
  • Threading. Should there be specifications what threads are used to call back into application code?
  • State Maintenance, Locking and Deadlock Avoiding. Are clients allowed to maintain state between an API call and its callback? If yes, then this introduces some kind of lock on the component, since the state must not be modified before the callback gets in. In other words, just becoming asynchronous is not a guarantee that locking and deadlocks are no issues. We could enforce a RESTful model without maintaining state, or re-invent scheduling rules in order to avoid the risk of data / state corruption or deadlock.
  • Boilerplate Code. Callbacks typically require code such as the following (the "myself" variable is not actually needed but added here for clarity what the code actually does):

final MyClass myself = this;
theService.invoke(new ICallback() {
    public void done(ICallbackResult result) {
        myself.moveOn(result);
    }
});

Such boilerplate code should be consistent across E4 in order to support tooling at some point (Or will we want some kind of precompiler until we have Java 7 closures)?

• The Device Debugging DSF Framework is the most elaborate framework for dealing with asynchronous requests and callbacks that I know. Looking at their Design Documents may be helpful.

Depencency Injection

• Any patterns on how to actually use it? And when to use it?
• Any initial code?

Application Model and Commands

• Will there be a new story for hooking up services, registering commands and reacting to them?