Humanizing OSGi II: Just saying no to old-style APIs
Look out, unbelievers. I’m on a crusade against the OSGi API’s these days.
Admittedly, it’s not that the OSGi API’s are bad. They are quite complete and completely workable. The impression you get, though, is that they could do with a brush-up and a make-over, give them that coat of wax. Make them more… modern. They’re old-school. But then, OSGi comes out of the embedded space, and wants to be as portable as possible, so this makes sense. But couldn’t we use, say, the Collections API?
Though I do like lots of the new-fangled Java features, I would argue against OSGi adopting them recklessly. Why? Because that’s not their job – they want to grow a mature, consistent platform. (Also, they’ve got IBM backing them – a virtual guarantee for glacial-at-best adoption of all the new and cool stuff.) It is a core technology, it can and should get away with being low-level and old-fashioned.
In short, OSGi targets a wide variety of execution environments, and tries to leave no (remotely relevant) configuration behind. It is you, the adopter, that gets to make the decisions that narrow this scope, and building good libraries on your platform of preference. Which, I suppose, would often involve Java 5 or 6.
If you want to build right on top of OSGi – maybe for some reason you can’t use any of those new application frameworks surfacing these days – you should invest some time in building a general, high-level, modernized API that fits your needs. Convenience methods and so on. Just so you can write more code dealing with your application, and less code dealing with putting values into java.util.Dictionary instances, or composing LDAP-ish query strings. Obviously, having everyone mess around this can produce lots of messy code, so that library support can be very useful.
I hope to get some time to outline some handy API’s for this purpose. First up is programmatic support for filter expressions – stay tuned.