Patrick Paulin is a trainer and consultant specializing in modular technologies such as OSGi and the Eclipse Rich Client Platform. He spends much of his time offering the RCP Quickstart course, which is meant to get software developers up to speed with Eclipse RCP. Patrick is also a regular speaker at technology conferences such as EclipseCon and Eclipse World. Patrick is a DZone MVB and is not an employee of DZone and has posted 24 posts at DZone. View Full User Profile

Why is OSGi Important?

  • submit to reddit

I’ve seen a number of blog posts and tweets lately asking some version of the question Why is OSGi important? If you’re one of the many people looking around at the increasing usage of OSGi and wondering whether it matters to you, here’s my answer.

I’m going to start by making a pretty audacious claim, which is that OSGi is one of the most important technologies to have arisen in the last 20 years. This does not mean, however, that OSGi is a revolutionary technology. In fact, OSGi is so important because it represents the logical next step in the long-term evolution of software development.

Where we’re coming from

To understand what I mean, let’s go back 20 to 30 years to the time when object oriented languages first became popular. One of the main reasons we adopted OO at that time was because it allowed us to hide many of the implementation details of our code.

Moving from procedural languages to OO languages allowed us to develop classes exposing a contract defined by a set of public methods.


The result was that much of our code was invisible outside of its class, and this had profound implications for the way we develop software. By accepting the apparent restriction of visibility we gained immense freedom. We gained the freedom to reuse classes without knowing their implementation details. We gained the freedom to refactor our code without worrying about the consumers of a class.

Can you imagine what a pain it would be if you had to develop software without information hiding?

Where we’re headed

Now imagine what it would be like if you could hide not only the methods within a class but entire sets of classes within a JAR. Imagine that JARs could define public contracts the same way classes do, and that these contracts would be enforced both during development and at runtime. Imagine that we could achieve all of the benefits of information hiding (managing complexity, code reuse, testability, refactoring, etc.) at an entirely new level.

OSGi makes this possible by offering up the standard Java package as a new unit of information hiding. When our code is running inside of an OSGi framework, each package in a JAR can be either exposed or hidden from consumers of that JAR.


Just as a class has a small set of public methods representing its contract with consumers, a modularized JAR (a bundle in OSGi terms) has a small set of exported packages representing its public contract. The bulk of our code lives in internal packages hidden from other JARs.

Imagine being able to rename classes, split or combine classes, move classes from one package to another, move entire packages from one JAR to another, all without having to worry about impacting the consumers of a JAR. So many of these types of refactorings are skipped now out of fear. Package level information hiding gives us the confidence we need perform these refactorings, allowing us to react with agility to the changing needs of our users.

Modularity is inevitable

Whether OSGi in particular succeeds or not, JAR level information hiding is inevitable. The benefits are simply too great to ignore, and in 5 or 10 years we’ll all be wondering how we could have possibly lived without it.

Currently, OSGi is the only tool we have to accomplish this. Luckily for us it’s a well though-out, well tested, standards-based solution. I can’t think of one reason (besides perhaps its name) to develop an alternative to OSGi. It’s here. It works. Let’s use it.

It’s time for OSGi

Steve McConnell has a great quote that really gets at the heart of what OSGi is trying to achieve.

In Code Complete, he writes:

Software development has advanced in large part by increasing the granularity of the aggregations that we have to work with.

Because this granularity of aggregation is so critical, the move from unmodular to modular practices is as important as the move from procedural to object-oriented practices. For 20 years we’ve been limited to using the class as our unit of abstraction. As successful as that has been, it’s time to move on to modules. Its time for OSGi.


Published at DZone with permission of Patrick Paulin, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jilles Van Gurp replied on Tue, 2009/05/05 - 2:30pm

OSGi in it self is not important except it is the first time that the ideas put forward in the component based software engineering community that emerged in the nineties are fully deployed in a widely used platform. I think in many ways, OSGi is not that great but I do appreciate that right now it is the only mainstream component platform that combines component isolation, api versioning and the notion of provided and required interfaces for components (i.e. bundles of functionality and not methods or classes or other traditional units of modularity). And of course it has some additional nice features.

You could see it as compensating for the lack of these features in the Java language or virtual machine platform. Which brings me to the obvious next step: these concepts need first class representation in a mainstream programming language. Such a language does not exist at this point. Arguably, .Net assemblies come close though. Unsurprisingly, one of the key authors in the afore mentioned research domain, Clemens Szyperski, works for Microsoft. His book on component based is still worth a read. However, Java+OSGI is superior to what .Net does at this point.

I believe Java annotations (technically very much inspired by .Net) with the underlying Java classloading mechanism and sandbox security model provides all of the key ingredients needed to come up with a next gen Component environment. Spring like environments provide some part of the puzzle here. In my view OSGI is still very messy to deal with. Lots of boilerplate code, legacy interfaces and restrictions resulting from that, poorly supported deployment environments, etc. It was designed for what is basically a side show now: embedded Java. Still interesting but Sun has not been particularly successful in convincing anyone of the notion of embedded Java (unless you count Google Android).

ramon wang replied on Tue, 2009/05/05 - 10:01pm

Nice article which makes OSGi clear to me,  however, I didn't see too many developers were using or trying to use this technology, so there must be a long way for OSGi, maybe still years to be a great tool that everyone have to use.

Michael Astreiko replied on Wed, 2009/05/06 - 1:28am

The best article to understand what OSGI is.

Jeroen Wenting replied on Wed, 2009/05/06 - 6:33am

If you need this much space to say why something is important, it isn't.

Patrick Paulin replied on Wed, 2009/05/06 - 10:48am

Hi Ramon, OSGi has been kind of a niche thing in the past, but that is mainly because developers didn't have anywhere to run their bundles. One major exception is Eclipse RCP and plug-in development. But now with products like SpringSource DM Server, ServiceMix 4, and JBoss OSGi developers have a way to deploy their applications in a modular way. Many developers are making the switch, and many more will do so in the next few years. --- Patrick

Jeroen Wenting replied on Fri, 2009/05/08 - 2:23am

forget it, Patrick. "in a few years" there will be something "new and improved" that's all the hype du jour and noone will even remember OSGi.

li yang replied on Tue, 2009/05/12 - 12:55am

May i say it like this:OSGi make abstract level from class to package? is it so useful as this article confirmed?

Albert Kurucz replied on Thu, 2009/05/14 - 4:49pm

Before you start to believe, this is all to know about OSGi, R.T.F.M.:


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.