In this post, I hope to illuminate that OSGi is not only the red-headed stepchild of Java development, but also quite helpful, when used by smart people on the right project. How delicious it was Tuesday night, when OSGi stood at the center  of one of the most helpful presentations I have seen in my 15 years of Java.

In this presentation, OSGi wasn't even trying. OSGi is like that.

Backstory: OSGI Sux

Thoughtworks Tech Radar suggests that OSGi is a doubtful technology. Enterprises have attempted OSGi implementations with great fanfare, and abandoned them in quiet desperation, with the hemoraging budgets to accompany this over the past decade. The internet is full of blogs decrying OSGi. 

I love OSGi. I'm not even that brilliant at it. But I automated all of my work to be OSGi centric years ago, and after I learned it's funny ways I think it's the cat's pajamas. But even just advocating it to a team of cowboy coders made me appear as an impractical, wasteful dreamer on an important contract. I learned to let someone else take the arrows for this otherwise great technology.

Last Night: Glory!

If you ever get a chance to hear Matt Pavlovich from mediadriver do a talk on Fuse (Apache Camel via Red Hat) you might feel as I did, that this was one of the best hours you ever invested.

  • great platform
  • huge corporate need
  • top notch presenter

OSGi wasn't even the topic - the topic was the brilliant capabilities that Apache Camel offers to the enterprise who understands and incorporates EIP or Enterprise Integration Patterns. And feature after feature, OSGi kept getting mentioned as one of the single most important technologies that enables Apache Camel to do it's work.

Why? Because EIP is one of the few areas that where being all things to all people really is an asset, not a liability. A successful EIP project may encompass thousands of 'routes' and have wrapped many different versions of the same binaries - all of which are used throughout different parts of the enterprise. 10 different versions of Log4J and slf4j - some with different APIs? Hey, no problem. OSGi keeps everyhing in it's own classpath - bring in 100 different versions if you like. No harm done.

Vindication is Rare in OSGi Land

OSGi is not for sissies, mostly it just gets trashed. But for the silly few of us who actually walk through the wall of fire and adapt it, the benefits can be great. Thanks to Apache Camel, for proving just that. And to Matt Pavlovich of mediadriver for a brilliant presentation on Fuse & Camel.