There have been bubbles of interest about OSGi in the Java community over recent years. I for one was very excited about the advent of a modular Java platform that freed us from the classloader issues in the JDK manifested best by Jakarta commons-logging (clogging our app servers).
OSGi was going to change everything, dependencies would be completely isolated (no more tripping over conflicting dependency versions), visibility and would be strictly enforced between each ‘bundle’. I was so bought into the promise of OSGi, like many others, I focused our engineering team on making Mule OSGi-enabled.
After months of our team wrangling with manifests, packaging our own bundles and endless fiddling with our build, the benefits of OSGi started to dwindle. ‘No pain no gain’ we thought, but then we hit our roadblock. How do we hide the complexities of OSGi from our users?
Great for Vendors
OSGi is a great specification for middleware vendors, but a terrible specification for the end user. This is because OSGi was never build for application developer consumption. Its roots lie in set-top boxes that needed to have software updates deployed to them remotely without any user intervention. It is a great specification for this type of software deployment since only the vendors needed to deal with deploying bundles.
Middleware vendors have jumped on OSGi because, frankly its right up our street. It promises to modularize software stacks and enable plug n’ play of your middleware infrastructure. Unfortunately, not even these promises are easily delivered with some bundles not working the same way across different containers.
Developer Burden
As if developers didn’t have enough to think about, OSGi adds another complexity to building applications. Furthermore, the promise of bundles working cross-container doesn’t always work, making re-use more painful too. Every developer-focused blog around-OSGi tends to be complex and steeped with technical detail that demonstrates that OSGi just isn’t ready for the developer yet. A technology like OSGi should almost be completely invisibile to a developer. The requirement on the developer should be to define an application in terms of modules but without the need to mess with manifest, bundles and build systems.
Is OSGi DOA?
The fundamental principles of OSGi are rock solid and we definitely need modularization on the JVM in order for it to flourish in its new defacto role of the polyglot platform. I think OSGi has potential but the user interaction part of it needs to be re-thought now that OSGi is being targeted at regular application development.
When we designed the hot deployment model for Mule 3, we took a lot of cues from OSGi (and avoided the pitfalls of the JEE classloader model). If the next revision of the OSGi specification made it easier for developers to work with OSGi bundles (maybe relying more on convention over configuration) the Mule team would be very happy to re-investigate. As it stands modularization and hot deployment is very possible on the JVM without OSGi and the pain of day-to-day development with OSGi out-weighs its benefits.
Follow: @rossmason, @mulesoft
