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
hargrave at us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788