Difference between revisions of "E4/Architectural Foundations"

Revision as of 19:15, 20 May 2008

From Architecture Council/Minutes May 15 2008#Executive Summary of the Discussion:

Too Many Listeners

• From Architecture Council/Minutes May 15 2008#Too Many Listeners, there are two distinct problems:
  • too many different listener classes -- need to unify on generic Listener architecture
  • too many listener instances -- a general Command Bus / Event Bus may help. Related to Application Model / Commands / Macro Recording.
  • Champions to sit and merge concepts from (EMF, DataBinding, Others)
  • Also see this older proposal for a common notification mechanism

Becoming More Asynchronous

• From Architecture Council/Minutes May 15 2008#Becoming More Asynchronous
  • Need a consistent overall picture; get above the level where we deal with these things one by one
  • Jobs and Scheduling Rules have some problems; DataBinding Realms and Runnables are good; We have too many Runnables; Futures could be a solution
  • Too many different ways of doing things, a more consistent Application Model would help getting more asynchronous
  • Consistent (machine-usable?) Documentation of Concurrency Properties
  • Recommend usage, e.g. Avoid Modal Dialogs; Verboten: Spinning the event loop
  • However, note lessons learned from the extension registry: data passed in asynchronous notifications should represent "an island"; it should be isolated from the current data with no way to navigate from the notification's data into the current data
• Pawel Piech (pawel.piech@windriver.com): If E4 is going to explore a new concurrency model for Eclipse, I think it ought to look at the DSF framework in the DSDP/DD project (the main concurrency package in DSF is here). It is based on the Executor, with the same extension as Realm to allow the caller to check whether he's in the executor thread. However the main communication method between realms is a callback object: RequestMonitor, the use of Future is avoided when possible because it easily leads to deadlocks. We've learned quite a bit over the last couple of years of using this framework and we'd be happy to share our lessons learned with E4, although I'm afraid I'm not able to attend the E4 summit.

Dependency Injection

• Closely related to Application Model -- If components (view, editor) shouldn't know about the context in which they appear, dependency injection is a technique for this. Instead of PlatformUI.getWorkbench.getHelpSystem(), have the HelpSystem constructor injected.
• Jeff: One of my favorites, has a fundamental impact on the entire Platform in terms of programming model, ease of testing etc.
• Need to take a look at the existing dependency injection mechanisms: DS, Springs, extension registry to see what works and what does not.
• Oleg: Not quite a dependency injection, but a related question from observing code patterns developers use. We see 100s of singletons per 1 OSGi service. This is a natural state as singletons are so much easier to use. Do we need to fight this or should we adapt to the use of singletons? The singleton and dependency injection should be complimentary, not mutually exclusive.

Java 5 Usage

• Should the Platform start using Generics and other Java 5 Concepts?
• Could there be tooling to allow writing code with Generics and other Java 5 Concepts, but still automatically convert the code into a variant that can also run on Micro Edition / Older JVM's ?

Scalability

• While the bundle lifecycle on the "activation" side is well defined now, the opposite end - unloading unused bundles seems to be murky on a number of levels.

Other Topics