In observer pattern (aka listener mechanism), the listener list may suffer concurrent access problem (if the application tries to read/call and write/add/remove concurrently). There are three solutions in Eclipse to handle concurrent : SWT: Uses its own EventTable to handle array copy to avoid OSGi: Uses the Event Manager framework. The event manager also handle event dispatch Eclipse Platform: Uses the ListenerList + EventManager. The event manager adds efficient resource handling on listener lister, without no dispatching abaility. Since OSGi approach also provide the execution function, the choice of our strategy should also consider this. Eclipse has four ways in executing unit of code: SWT: Display sync execute OSGi: Event Manager with event dispatch Eclipse Platform: SafeRunner is used to execute runnable in an exception handled way Eclipse Job API: concurrency + progross monitor support It seems the event manager from OSGi is more difficult to code against, and is not multi-threaded. Also there is no way to get notification if an event has been dispatched. SafeRunner is also a problem because it is single threaded. The choice of execution goes to Job API. It also provide notification and delay operation on the job for execution. Now, the problem is either running each listener as job or run all listener under the same job. Base on the benchmark, the former takes about 5-15ms to run 10 simple listeners, and the later one takes 6-16ms to run 10 listeners. So there is no significant performance hints on both approaches. The final choice for us is ListenerList + Generified EventManager + Job API.