The basic "issue" is that OSGi services only exist when the bundle has been activated (STARTING | ACTIVE | STOPPING). They require the bundle to execute, create the service object and register it. (vanilla service layer without something like Declarative Service, Spring OSGi, iPOJO, etc). So if you have 1000 bundle and 10000 services, there is a lot of work to be done to get those 10000 service all registered.
Eclipse Extension point are just data (despite other possible opinions, the extension registry holds no live objects, it only provides helpers to converts a class name into live objects, but running code must call these helpers). You can think of the extension registry as a large DOM with many bundles contributing document snippets to the overall DOM. Since the DOM only contains data, which is very simple to persist, and is defined by static files (plugin.xml), once the DOM is constructed, it can be quickly serialized and deserialized. So a system of 1000 bundles and 10000 extension can be deserialized without loading any code from the 1000 bundles. Also, since they are just data, a bundle only need to be RESOLVED for its contribution to the DOM to be active. Thus Eclipse Extension Points "scale better". But you are comparing grapefruits to oranges. Yes they look rather similar, but they taste different. They are different tools in the arsenal of the programmer. Jeff McAffer did a presentation at EclipseCon 2006 on this and I have started the "definitive" :-) paper on this topic but have not yet finished. I only seem to make any progress when offline and stuck in an airplane... Well JavaOne is coming up, maybe I will make some more progress on the paper :-) BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
