E4/Architectural Foundations

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

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.