Neil’s point-free blog

One of the great advantages of the Declarative Services (DS) approach to OSGi development is laziness. If you listened to the podcast interview with Chris Aniszczyk on EclipseZone recently, you might think that laziness in DS is a special, new-fangled feature in Equinox 3.5 that requires funky bundle activation states. Frankly it sounds complex and scary. But in fact DS laziness can be quite simple and clean if we eschew a little bit of Eclipse/PDE baggage.

First let’s just explain what we’re talking about here: OSGi services are used to decouple the producers of functionality from consumers. For example consider a Translator interface. A “producer” may offer an instance of this interface to translate English strings into Klingon, by publishing it as a service. A “consumer” needs to know how to say “revenge is a dish best served cold” in Klingon, so it queries the service registry to find an instance of the Translator interface and then invokes the translate method. This model is wonderful because the producer knows nothing about the consumer and the consumer knows nothing about the producer: they are perfectly decoupled. But in one way it is too decoupled: the producer doesn’t know whether any consumers even exist!

Suppose that setting up a full English to Klingon translation service takes some time and memory; we wouldn’t want to do it unless we were sure that at least one consumer exists. At the very least we should defer creating it until an interested consumer comes along, so that we don’t unnecessarily delay the startup of our application. Imagine if our application was constructed out of hundreds of services, each of which has a non-negligible cost to create, but only a fraction of which may actually be used by a real consumer.

Typically though, services themselves are not very expensive at all. Most are simple stateless Java objects with a very low marginal instantiation cost. But in the traditional, eager approach to service registration we must at least create a classloader for the bundle in order to load the service implementation class and instantiate the service object, and in large systems the cost of all those classloaders may be quite high.

Enter DS. If we declare our Translator service in an XML file, then the DS runtime bundle is able to register an entry in the service registry before actually creating the implementation class for the service. Only when a consumer comes along wishing to use the service does the implementation class actually get loaded. Handily, this all happens completely transparently to both the consumer and the producer.

However there’s a little wrinkle which, at first glance, makes this seem rather pointless: DS will ignore our bundle and all the lovely XML declarations it contains unless it is in the ACTIVE state! This is very important, by the way, because ACTIVE state gives us explicit control (contrast with the Extension Registry in Eclipse which looks at RESOLVED state, and there is no way to explicitly move a bundle in and out of RESOLVED state). However, activating the bundle means running its activator, which means loading the bundle and creating a classloader and all the other stuff that we just said was expensive. This is the point where some people get confused and start looking to the fancy-schmancy “lazy activation policy” stuff introduced in OSGi R4.2. But wait a minute… what if the bundle has no activator?

The key point here is that bundles can still be active even without an activator class. This may seem silly; what is the purpose in activating a bundle if it has no activator? Well in that case, the ACTIVE state is merely a flag that tells DS to look at the bundle. Now activation is free because there is no need for the framework to create a classloader, as there is no activator class to load.

Therefore, the simplest approach by far to developing services with DS and benefiting from laziness is to build bundles without activators. As far as I know, this works with all OSGi R4.x implementations.

So what’s all the lazy activation policy stuff in OSGi R4.2 about? Well I believe this is because Eclipse wants to have its cake and eat it. The problem is most legacy Eclipse plug-ins do have activators, and furthermore the “New Plug-in” wizard in PDE offers to generate an activator class for you by default. All these activators barely do anything useful and they get in the way of using DS lazily. Eclipse wanted to have activators and delayed classloader creation, so the OSGi spec was enhanced (i.e., made more complicated) in R4.2 to allow bundles to be “lazily started”. This means they enter a kind of limbo where they hang in the STARTING state — a state that normally only exists briefly during the execution of the activator. In this state the bundle classloader has not yet been created and the activator has not yet been executed, but DS can see the XML service declarations and can register the services. As soon as a consumer requests the service, then the classloader is created, the activator is executed and the service instantiated. Yikes, bundle lifecycle is difficult enough to explain already!

There are some nice enhancements in DS in OSGi 4.2 though. The most noticeable is that it is now much easier to write DS components as POJOs, because the activate and deactivate methods are no longer required to take a ComponentContext parameter, and they can therefore be written without any dependency on the OSGi APIs. Also they can receive configuration data from the Configuration Admin service via a Map parameter, and they can be made dependent on configuration data being available.

Sadly, the laziness of DS has its limits, no matter whether we use the no-activator approach or the lazy activation approach. In a DS component we declare references to other services; for example the Translator service may refer to a Dictionary service to look-up the meanings of individual words. DS will see this declaration and supply the Dictionary service to our Translator service implementation via the bind method, e.g. a setDictionary method. This is enough to count as “using” the Dictionary service, which will cause the implementation class for the Dictionary to be loaded and so on, even if our Translator doesn’t really need to use the Dictionary until much later on. There is a way around this problem: instead of asking DS to supply the Dictionary object, we can ask it to supply a ServiceReference object, which we can use later to get the Dictionary when we really need it from the ComponentContext. Unfortunately this pollutes our code with OSGi API calls: our components are no longer POJOs. The only OSGi component model that I know of that avoids this problem is iPOJO, which in this scenario would inject a proxy Dictionary object into the Translator wait until the translator actually accesses the dictionary field before fetching the dictionary service object (thanks to Clement for correcting me on how this works).

Anyway, I enjoyed the interview with Chris, and the DS component editor introduced in Galileo should be very handy — if only it worked outside of PDE projects!