OSGi

From APIDesign

wikipedia::OSGi is a specification of a modular system for Java. It defines packaging format (JAR file with additional manifest entries and associated troubles), runtime behaviour and a way to register and discover services. In contrast to NetBeans Runtime Container, it supports package dependencies. Otherwise the systems seem similar which has been demonstrated by implementing OSGiAndNetBeans bridge.

OSGi Weirdness

OSGi and NetBeans Runtime Container are similar, however the devil lays in details! From time to time I manage to learn more about OSGi and then I just cannot stop wondering what was a motivation to design behavior like this! Maybe this is all caused by my pre-occupation (as a designer of NetBeans system), but I just cannot overcome a feeling that certain design decisions in OSGi are just weird.

I'll nitpick on OSGi here hoping somebody will be able to explain the history and possibly also rationale behind these (mis)behaviors.

Start/Stop a Bundle

I believe it make sense to tell a module that it is going to be used or it is used no longer. Of course, I'd rather preffer Declarative Programming, but sometimes there is just no way around and the necessary parts of infrastructure need to be turned on. Thus it is makes sense to have a BundleActivator or ModuleInstall (in the NetBeans case). However then one finds out that people can use an OSGi bundle without starting it!

What kind of crazy idea is that? It basically means I cannot put any initialization logic into the activator/installer at all. I need to be ready for somebody using my module without starting me! I really don't get the purpose of this construct at all. In NetBeans the installer is guaranteed to be called whenever somebody tries to enable a module, or use it (by having a dependency on it and trying to get enabled). This sounds logical to me.

Obviously these misconceptions complicate the OSGiAndNetBeans bridge. Basically it means there is no 1:1 mapping between enabling a module in the NetBeans sense and starting a bundle in the OSGi sense. As we discover more and more OSGi based systems (like JDeveloper), we need to add more and more flexibility to cover all the possible ways people deal with the dichotomy between used and started. OSGi is more flexible, but unlogical.

Range Dependencies

One of characteristics of OSGi is use of RangeDependencies which seems like a clever good idea supporting cluelessness in its way, but at the end it is just a way to NP-Complete problems. An example when simple, less powerful systems would be more effective.