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.

One Response to “Humanizing OSGi II: Just saying no to old-style APIs”

  1. Hi Kjetil, I largely agree with you, and it would be great to see an open source project to centralize some of these efforts, rather than every man and his dog implementing their own filter API, generified ServiceTracker and so on.

    As much as I love OSGi, there’s one part of the API that I really hate: whenever you call a query method returning an array, such as getServiceReferences(), if there are no matches then you will get back a null rather than an empty array. So you have to put a null-check after every damn call! Apparently back in 1995 it was considered a useful optimization to avoid allocating a *single* object for the entire API: public static final Object[] EMPTY = new Object[0];

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: