Why is OSGi important?

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 to 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.


6 Responses to Why is OSGi important?

  1. Tom says:

    Hi. I must say I totally agree with you. It’s funny people adopted encapsulation on class level but don’t feel the need for the same on jar level.
    Not being an expert on OSGi, I have ask what level of support is there for design/compile time enforcement at the moment? Let’s say how soul we achieve that in Eclipe?

  2. Patrick says:

    Hi Tom,

    During development, the Eclipse compiler is completely OSGi aware and provides appropriate warning and error messages based on what packages are exposed (or not) in a bundle. The visibility of packages is set in the JAR manifest file, and these settings are used instead of what you would normally set with the Java Build Path dialog.

    It works extremely well. All you need is Eclipse and the Plug-in Development Environment to get started.

    — Patrick

  3. Pablo says:

    Hi, I’m the author of SO question where you linked this post, and I’ve read it.

    My question is: can’t this kind of ‘JAR encapsulation’ be achieved by simply choosing which classes of our JAR are public and which are private / package-private, in other words, by defining our JAR public API?

    I’ve been doing this for years without a problem, and (more important) without the need for OSGi.

    Based on other comments I thought that OSGi was useful only in a heavy-enterprise-application where you need to swap modules and downtime is not an option.

  4. Patrick says:

    Hi Pablo,

    It’s true that you can achieve some level of information hiding by making classes package protected, but what you’re really doing is making the Java package your unit of abstraction. There are a number of problems with this:

    * Packages are fairly fine-grained, closer to classes than JARs. To achieve the kind of encapsulation we’re talking about you would need to hide a *lot* of classes. Unless you put all of your code into a few very large packages, managing the relationships between classes inside the JAR would be difficult.

    * Packages are not the unit of deployment. One of the benefits of modular JARs is that we are aligning our unit of abstraction with our unit of deployment. Because modules/bundles have public APIs, different implementations of those APIs can swapped in by deploying new JAR files. This becomes something like the relationship between interfaces and classes.

    Again, I’m not arguing that you can’t achieve some level of encapsulation using package protected classes. But I would argue that it’s very difficult to build modular software in this way. One of the benefits of object-orientation was that it made it easier to things the right way than the wrong way. OSGi is the same, it almost forces you to make the right decisions. While this might be frustrating initially, I think its definitely worth it in the long run.

    — Patrick

  5. Pablo says:


    I should give OSGi a serious try in order to speak with a bit more of a background. Nevertheless I believe encapsulation/information hiding is highly overrated (and IMHO underused) this days.

    DI needs to break encapsulation in order to work.

    More dynamic languages tend to be more flexible in this topic (in groovy for example, you can access any field, even private ones).

    Even in Java, average coders tend to create an accessor/mutator pair to every field, exposing the inner components of every class (this is often called anemic domain model).

  6. John Bäckstrand says:

    I don’t see how DI and encapsulation are exclusive, as you make it sound like: isn’t the point with services that they are in fact configured elsewhere, meaning DI is “inherent”?

    Pablo: I think anemic domain model is about more than just exposing every field in a class: a domain object could very well be non-anemic and still have every field mutable, I think. Anemic is more about the operations _other_ than the setters/getters: if there are higher abstractions, its probably not anemic. If it is just a class with no operations other than changing values, then it is anemic. Otoh, it could be anemic with no setters!

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: