E4/Architectural Foundations

From discussions at the e4/Summit and Architecture Council/Minutes May 15 2008#Executive Summary of the Discussion:

Singletons

• General consensus that singletons are bad and should be avoided.
• Oleg: 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. Yes, singletons are easy to use, but only until you realize that you need two of the same kind (and only if it's for testing purposes). Then going through the code and getting rid of assumptions like that there is only ever one Workspace is really hard. -- BorisB

Dependency Injection

• Consensus that dependency injection is good. Has a fundamental impact on the entire Platform in terms of programming model, ease of testing etc.
• Clients should be able to "just write POJOs" and list the services they need.
• Concerns about discoverability of services - cannot use code completion to find out what is available.
• Like to avoid containerisms - having code that makes assumptions about which context it is being used in.
• Can be used at different levels of granularity. Do you inject small individual services, or larger objects that provide more functionality?
• 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.
• Need to take a look at the existing dependency injection mechanisms: DS, Springs, extension registry to see what works and what does not.
• Observation that we don't see dependency injection frameworks for dynamic languages (JavaScript, Smalltalk, Ruby). Why is that?

API Consistency

• One consistent API to access/modify/listen to tree-shaped structures for things like preference store, extension registry, IMemento, etc.
• How can we describe API in a language-independent way?

Too Many Listeners, Event Storms

• There are three 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.
  • event storms -- really big cause-and-effect trees, leading to duplicate work in listeners that get hit more than once, or doing too much work by being eager instead of lazy.
  • Champions to sit and merge concepts from (EMF, DataBinding, Others)
  • Also see this older proposal for a common notification mechanism

Security

• Different levels of security:
  • Making sure that only signed code is deployed.
  • Making sure that only signed code is loaded.
  • Ensuring that code cannot do certain things like accessing the local disk etc.
  • Having application-level concepts like user/session/roles.
• Maybe it is good enough to cover the first two levels?

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.
• Scott Lewis (slewis at composent.com): It would be useful to have multiple primitives for interprocess and inter-thread communication...e.g. proxy (blocking/call return), async w/callback, futures/asychresult. ECF has a remote services API that provides these primitives for services, with an explicit approach for handling partial failure...via methods exposed by IRemoteService interface. Also, replicated models should also be considered, and the ECF shared object API can/could be used to support such approaches.

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.

Summit Notes for Java 5/supported platforms

• are we stuck with Java 4 forever? Why have we stuck with it up until now? It's less about the language than it is about the libraries
• the community is divided here sharply - embedded folks (and their ilk) do not want Java 5 - they fear bloat. However, there is a large portion of the community that is resistant to using old technology.
• if our modelling is based on EMF and we're exposing that model, we're either using an old version of EMF or we're brought along to 1.5 by default
• do we need multiple versions of the API? The problem is beyond the 1.4/1.5 split - generating APIs for any other language we want to target is also an issue
• can we compile 1.5 language (not libraries) into 1.2 bytecode? perhaps
• do we need to hand craft bindings for every supported language?
• can we use 1.5 java as the IDL for generating the various language bindings?
  • some possible languages we should think of. Not that we're necessarily supporting these out of the box, but we should think about them as constraints on our API:
    • Java 1.4
    • Java 1.5
    • Javascript
    • Lisp
    • C
    • Objective-C
    • C++
    • Scheme
    • Ruby
    • Groovy
    • PHP
    • Action Script
    • C#
    • REST
  • how do we handle object lifecycle between GC and non GC language? Also constraint on API
  • exception handling is also an issue
  • how about closures?
  • subclassing is also problematic
  • concerns here - we will need tooling to ensure that the API we generate can target the various languages we support. Ie: overloaded methods are problematic for javascript.
• API is differnet from implementation - we should be careful of what libraries we drag in
• "classic" SWT will live on, but the snazzy new e4 features are targetted at:
  • 32/64 bit Cocoa (OS X)
  • WPF (Win)
  • Flex 3 (Flash 9)
  • Motif is our first compatibility casualty - the lack of reparenting has been an obstacle for a very long time and will prevent us from doing our workbench modeling going forward