Alternative OSGi Styles

When you spent most of your daily life worrying about extremely detailed Java class loader peculiarities then you tend to start thinking that what you’re doing is really important. This feeling is amplified when you see all those important people taking it really serious. And then you suddenly get confronted by a group of people that completely violate our specification but still do something very interesting.

I am talking about osxa. They looked at our specification and decided that the goal was lofty but that it contained too much unnecessary cruft for them. They just took the interesting 80% (well for them interesting) and ignored the rest. I almost took it personal, but they just put all bundles on the class path! Ok, it meant that they did not need class loaders anymore and that opened a larger range of deployment scenarios. For example, they can deploy their applications in a JNLP web start without the need for signing.

Obviously this implies they have no proper isolation between bundles; bundles can conflict in their packages. However, this is isolation is not always needed, especially when the set of bundles that gets deployed together is fixed. These conflicts can then be resolved ahead of time.

And this is the different, surprising, perspective that they took. They love the service registry and do not care about the module layer. They needed a model where they could use many different components, bunch them up together, and deploy them as a whole in a JNLP deployment or inside web app server. What me worry about bundle life cycles?

Actually, when I realized how much they liked the service registry, I could not stop myself from warming up to them. I am often told that the real important stuff of the OSGi is the module layer. The service registry is just a hanger on. In JSR 291 we actually tried to remove the service registry to simplify the specification. We did not because the module layer and the service registry were very hard to separate. However, I always liked the services most; for me, the module layer was the necessity but the services were interesting.

Obviously the osxa people trample over our carefully crafted specifications. However, I think their perspective is interesting. I think it demonstrates the power of the specification that you can write bundles that will run in a compliant framework but also in something that is wildly different. I have always felt that bundles are the important parts; as long as bundles can write against a good specification, then framework developers should be allowed a lot of leeway. It is interesting to see how they use quite a few equinox bundles.

Anyway, the osxa will not receive compliance anytime soon because they completely discard the module layer and take a lot of liberty with other aspects. They can therefore obviously not call themselves an OSGi framework implementation and developers should be very careful not to target any of the peculiarities of this framework. Still it is interesting to see that the success of the OSGi specifications is enabling these initiatives. Initiatives that can have value in certain circumstances and clearly prove the viability of the OSGi model.

Now, if they only could get their demo working again …

     Peter Kriens