Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "E4/Architectural Foundations"
< E4
(→Architectural Foundations of Eclipse) |
|||
| Line 6: | Line 6: | ||
** '''too many listener instances''' -- a general Command Bus / Event Bus may help. Related to Application Model / Commands / Macro Recording. | ** '''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) | ** Champions to sit and merge concepts from (EMF, DataBinding, Others) | ||
| + | ** Also see [http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg03224.html this older proposal for a common notification mechanism] | ||
== Becoming More Asynchronous == | == Becoming More Asynchronous == | ||
| Line 14: | Line 15: | ||
** Consistent (machine-usable?) Documentation of Concurrency Properties | ** Consistent (machine-usable?) Documentation of Concurrency Properties | ||
** Recommend usage, e.g. [[Architecture Council/Minutes May 15 2008#Avoid Modal Dialogs|Avoid Modal Dialogs]]; [[Architecture Council/Minutes May 15 2008#Verboten: Spinning the event loop|Verboten: Spinning the event loop]] | ** Recommend usage, e.g. [[Architecture Council/Minutes May 15 2008#Avoid Modal Dialogs|Avoid Modal Dialogs]]; [[Architecture Council/Minutes May 15 2008#Verboten: Spinning the event loop|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 == | == 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. | * 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. | * 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 == | == Java 5 Usage == | ||
* Should the Platform start using Generics and other Java 5 Concepts? | * 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 ? | * 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 == | == Other Topics == | ||
[[Category:e4]] | [[Category:e4]] | ||
Revision as of 16:02, 20 May 2008
From Architecture Council/Minutes May 15 2008#Executive Summary of the Discussion:
Contents
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.