Craig Walls has been professionally developing software for over 14 years (and longer than that for the pure geekiness of it). He is the author of Spring in Action (now in its second edition) and XDoclet in Action, both published by Manning and is currently writing about OSGi and Spring-DM. Craig has posted 9 posts at DZone. View Full User Profile

A Dozen OSGi Myths and Misconceptions

  • submit to reddit

Anybody who knows me or has been following me lately knows that I have an interest in OSGi. And I'm not alone--there has a lot of buzz about OSGi in the past few years.

But as I talk about OSGi with other developers, I often hear them say things about OSGi that simply aren't true. It's not their fault, though. Unfortunately, there's a lot of misinformation and misconceptions about OSGi out there. It's hard to sort out the good information from the bad. And more often than not, it's the bad information that sticks with people.

There's no perfect technology and OSGi isn't going to be nominated as the first one. But before you give OSGi the brush off, let me try to set the record straight on a few of the OSGi myths and misconceptions that I've heard.

OSGi is too complex

I've been told that OSGi is too complex because it requires rigorous management of the META-INF/MANIFEST.MF file (you know...that file that's in every JAR file...the on you never look at).

It is true that OSGi leans on the MANIFEST.MF file and that you'll need to make sure that the manifest contains entries that you probably wouldn't normally put in there. But it's also true that OSGi only demands one additional entry in MANIFEST.MF for a JAR file to qualify as an OSGi bundle: Bundle-SymbolicName.

Bundle-SymbolicName is used to identify a bundle (the unit of modularization in OSGi) to an OSGi framework. It typically follows an inverted domain name pattern (similar to how Java packages are named). For example, the Bundle-SymbolicName header for a simple hello world bundle might look like this:

Bundle-SymbolicName: com.habuma.osgi.helloworld.hello-simple

Of course, if all you did was add a Bundle-SymblicName header, you'd have a perfectly valid OSGi bundle that is also perfectly useless. For it to be useful, the bundle needs to...

  • Export one or more packages. Packages within an OSGi bundle are private by default, meaning that they are only visible to classes within that same bundle. For them to be used by other bundles, they must be exported. This involves adding one or more package entries in an Export-Package header in the manifest.
  • Publish one or more services. Services are the way that bundles talk to each other. A bundle can expose its functionality through one or more services. This involves either using a declarative services model such as Spring Dynamic Modules or by creating a bundle activator class that programatically publishes the service through the OSGi API.
  • Do something. Bundles do not have to expose any of their functionality through exported packages or services. They may just sit there and churn on something. For that, the bundle needs to have a bundle activator (or, if you're using Spring-DM, a <bean> with an init-method).

Although there are several headers that you could include in a bundle's MANIFEST.MF, there are only a few that you'll probably ever use. And even then, much of the management of the manifest can be automated using tools such as Peter Kriens' BND (more on this later when I talk about OSGi tools).

Maybe it's not manifest management that makes you think OSGi is complex--perhaps the OSGi API causes you some concern. In that case, consider this: The OSGi API is made up of only a half-dozen different packages and mostly interfaces. Of those, you'll likely only ever need a handful of them.

Even then, you'll probably never even need to use the OSGi API at all. But I'll continue that discussion in the next item...

OSGi is too heavyweight

Whenever I hear the word "heavyweight" in the context of a technology or framework, it usually means that the framework imposes itself and its APIs too heavily upon an application's code. EJB 2.x, for instance, required that EJB implementation classes implement base EJB interfaces and implement a number of lifecycle methods. Consequently, EJBs were considered heavyweight.

On the surface, the OSGi API does appear to be a bit heavyweight. Bundle activators, for instance, are classes that implement the BundleActivator interface, providing start() and stop() methods. For example, here's a simple hello world bundle activator:

package com.habuma.osgi.hello.internal;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public final class HelloActivator implements BundleActivator {
public void start( BundleContext bc ) throws Exception {
System.out.println( "Hello World!" );

public void stop( BundleContext bc ) throws Exception {
System.out.println( "See ya later!" );

The fact that this class imports org.osgi.framework.* interfaces and classes should tip you off that we're not dealing with a POJO. But before you dismiss OSGi as heavyweight, consider this:

  • When developing to the OSGi API, the only classes that really need to implement and use the OSGi directly are the "plumbing" classes that publish and retrieve services and that manipulate the OSGi framework itself. The OSGi API typically doesn't invade the classes that provide your application's business functionality.
  • You often won't need to develop to the OSGi API anyway. It's much easier and more lightweight to use a declarative service model such as OSGi's Declarative Services, iPOJO, or Spring Dynamic Modules. Using these facilities, OSGi services can be published and consumed as POJOs.

Using declarative OSGi, iPOJO, and Spring-DM are topics that are beyond the scope of this article. But I do cover Spring-DM in Modular Java. And watch this blog space for more discussion on it soon.

OSGi isn't a "standard"

Personally, I'm not sure that it should matter much whether something has been stamped as a "standard" or not. After all, Spring isn't a standard. Hibernate isn't a standard, either (although JPA was heavily influenced by it). For that matter, Ruby on Rails isn't a standard. Despite their lack of standardization these frameworks are rarely questioned anymore for their lack of a JSR. Solutions, after all, are more important than standards.

But, if it standards are something that's important to you or your organization, then rest easy knowing that OSGi is, in fact, a recognized Java standard.

Aside from self-standardization applied by the OSGi Alliance, OSGi R4.1 is also the subject of JSR-291 from the Java Community Process. This JSR was given final approval and was released in mid-2007. The ballot included 12 votes in favor (The Apache Software Foundation, SAP AG, BEA, Hewlett-Packard, Nortel, SAS Institute Inc, Borland Software Corporation, IBM, Oracle, Fujitsu Limited, Intel Corp., and Red Hat Middleware LLC), two votes against Those voting against it were (Sun Microsystems Inc. and Hani Suleiman) and two members did not vote (Google and Doug Lea).

In addition, the mobile application of OSGi is the subject of JSR-232 (which is also in final release/maintenance release status).

OSGi is too new

Despite the fact that OSGi has only recently been grabbing the attention of Java developers, OSGi has been around a lot longer than many other readily-accepted technologies. In fact, OSGi celebrated its 10th birthday last month. In its time, OSGi has reached many milestones:

  • March 1999: The OSGi Alliance was founded
  • May 2000: OSGi Release 1
  • October 2001: OSGi Release 2
  • March 2003: OSGi Release 3
  • October 2005: OSGi Release 4
  • May 2007: OSGi Release 4.1
  • Sometime in 2009: OSGi Release 4.2

To put OSGi's age in perspective, consider the "birthdates" of these other technologies and where OSGi falls in:

  • 1995: Java 1.0
  • 1995: Ruby
  • 1996-1997: DVD
  • December 1998: Java 2
  • May 2000 OSGi Release 1
  • February 2002: Microsoft .NET
  • February 2002: Blu-ray Disc
  • March 2004: Spring 1.0
  • July 2004: Ruby on Rails

OSGi has been around nearly as long as several established technologies and has been around much longer than many others.

OSGi isn't ready for the "real world"

The precise definition of "cutting-edge" is up for some debate. Regardless of how you define "cutting edge", there are several projects out there that have been comfortable enough with OSGi to use it. Considering just a few examples...

  • Siemens Medical Solutions and ProSyst Software developed solutions for maintenance of medical devices in the area of image management systems using OSGi. (I love this example because the cliché criteria for how established a technology is if you'd use it to launch rockets or save lives.)
  • Philips developed its iPronto wireless home control panel using OSGi.
  • BMW Research develop innovative "infotainment" and telematic systems in automative projects that are based on OSGi.
  • Since version 3.0, the Eclipse IDE has been based on OSGi.
  • Virtually every major Java application server vendor is engaged in working OSGi into the server products. SpringSource is leading the way with their SpringSource dm Server, the first application server to fully expose OSGi's modular capabilities to application developers.

For more examples of projects that have placed their faith in OSGi, have a look at OSGi Markets and Solutions. And I'm certain that the list isn't complete--let me know if you hear of an interesting use of OSGi that isn't listed.

There aren't many OSGi tools

Perhaps my problem with this myth is that I'm unclear as to how many tools are needed to negate it. Certainly, I will acknowledge that there are some tools that I wish I had when working with OSGi. But I also do not believe that there is a dearth of OSGi tools as some have suggested.

When it comes to OSGi tooling, the very first tool that comes to mind is Peter Kriens' Bnd. Bnd is a remarkable little tool for creating and diagnosing OSGi bundles. Using BND, you can view the manifest and JAR contents of a bundle, wrap a non-bundle JAR file so that it becomes an OSGi-ready bundle, create a bundle given a specification and class path, and verify the validity of a bundle's manifest.

What's particularly interesting about Bnd is that although it comes as a single JAR file, it is actually three different tools in one. If you run it with java -jar bnd.jar, it is a command-line tool. If you add it to the Eclipse plugins directory, it is an Eclipse plugin. And, it has an Ant task built into it, so you can use it in an Ant build.

A fairly recent addition to the OSGi toolbox is SpringSource's Bundlor. Bundlor seems to address many of the same problems as BND, but is supposed to overcome some of BND's limitations. I haven't had a chance to try Bundlor out yet, but from what I read, it looks very powerful. When I get around to trying it out, I'll be sure to blog about it here.

There's also a huge set of OSGi tools available from the OPS4J Pax project. I've already reviewed these tools on this blog, so I won't go into it again here. Suffice it to say that many of the Pax tools have become indispensable in my OSGi development toolbox. I'm particularly fond of Pax Construct, Pax Runner, Pax Exam, and Pax URL. You can count on me blogging more about the Pax tools soon.

Apache Felix is known as one of the leading OSGi frameworks. But Apache Felix also has several subprojects that provide OSGi tools. The vast majority of the Felix subprojects are runtime tools, such as File Install (which automatically installs and uninstalls bundles from a watched directory) and Web Console (which provides a web-based administration console for an OSGi framework). Apache Felix subprojects also include the Maven OSGi Plugin, which is a very handy Maven plugin for automatically generating bundles (with proper manifests) in Maven builds. (BTW, Pax Construct leans heavily on the Apache Felix bundle plugin, which itself leans heavily on BND.)

If you take a visit to, you'll find several more useful OSGi tools and libraries. I've not tried any of these out yet, but several of them look very interesting and I hope to give them a spin sometime soon. (If I do, I'll be certain to blog about it here.)

These are only a few examples. If you look around, you'll find a lot of useful OSGi tools...even OSGi tools that work within your favorite IDE. And that brings me to the next item...

OSGi is for Eclipse users

If you've spent any time on Google looking for information on OSGi, you'll find several articles that discuss OSGi in the context of the Eclipse Plug-In development environment (PDE). That, coupled with the fact that one of the major OSGi implementations is produced by the Eclipse Foundation, may lead some to believe that you must use Eclipse to develop OSGi-based applications.

The truth, however, is that there's nothing about OSGi that makes it proprietary to any development environment. Certainly, Eclipse has provided the best IDE for OSGi development for a long time. But if you're an IntelliJ IDEA user, then you should check out Osmorc, a plugin for IDEA that provides support for OSGi development. I am also hearing rumors that NetBeans support for OSGi development is in the works.

That said, I frequently find myself working with OSGi bundles using a text editor like TextMate. That's because most of the OSGi-related work doesn't require anything more advanced than a simple text editor (apologies to TextMate...anyone who has used it will attest that it is far more than just a simple text editor).

OSGi is a solution looking for a problem

I almost didn't include this one. I've been in the software development game for a long time and I know that anytime someone wants to discount a technology or framework, the killer phrase that is almost always thrown about is "XXX is a solution looking for a problem" (or its variant: "XXX is a hammer looking for nails"). But just because someone says it doesn't mean that it's true. But I heard someone say this again recently, so I tossed it in.

I've also been doing this thing long enough to know that modularity is a good thing. Developing software in modules increases maintainability, testability, flexibility, and comprehensibility. It also offers benefits in terms of parallel development and (to some degree) reusability. Many languages such as Modula-2 and MIL-75 have been around for a long time and were created with modularity as a primary concern. Ask around...most everyone will agree that modularity is a desirable trait of good software.

Unfortunately, as awesome as Java is, it doesn't offer a lot of help with regard to modularity. JAR files and packages give only the illusion of modularity. And although there's a certain amount of modularity at the object level, that flavor of modularity is at too low of a level to be truly useful for creating modular applications.

For what it's worth, I'm not sure that modularity should be a language-level concern. My opinion in this matter is shaped by the fact that there are several wonderful languages for the Java platform and I wouldn't want modularity added to the Java language, leaving other JVM languages such as Groovy and Scala to solve the modularity problem for themselves. The fact that OSGi offers modularity at the JVM level and not at the language level means that it implicitly works for Groovy, Scala, or any other JVM language that I may want to build my modules with.

So, if modularity is a good thing and Java doesn't offer support for it, then...well...that sounds a lot like a problem to me. A problem begging for a solution, some might say. And modularity is one of the key things that OSGi offers. So, in my opinion, OSGi is a timely solution to the problem of Java's missing modularity.

I can get modularity without OSGi

It's certainly true, to some extent, that you don't need OSGi to achieve modularity. With the right mindset and a lot of discipline, you can develop Java applications that are modular to some degree.

But the problem is that there's nothing in the Java platform to encourage modularity, much less enforce it. And even the most disciplined and well-intentioned Java developers make mistakes. In short, if modularity isn't enforced, then it probably doesn't exist.

OSGi doesn't strictly enforce modularity (with some misguided cleverness, you can develop poorly defined OSGi modules, too), but OSGi does strongly encourage good modular development. With OSGi, it's easier to develop modularly than not to.

So, is possible to achieve modularity without OSGi. In the same way, you don't need Spring to do dependency injection. And you don't need an ORM solution like Hibernate or JPA to do object persistence. And you don't need an IDE to develop in Java. And you don't need JUnit to write well-designed, working code. You don't need any of that stuff...but I wouldn't want to give any of them up.

Speaking of testing...

OSGi is difficult to test

Inside of every OSGi bundle is a bunch of Java code that, if well-written, can be tested using JUnit or whatever testing tool you prefer. As with any Java codebase, you are free to write tests at the unit level and also to write cross-unit integration tests.

OSGi doesn't make testing harder--you can still test your code the same way as you do without OSGi. But OSGi offers a new level of testing--integration testing at the bundle level.

Bundle-level testing involves deploying one or more OSGi bundles within an OSGi framework (such as Equinox or Felix) and then making assertions about how those bundles work together, what packages they export, and (even more interesting) the services that they expose.

Testing OSGi bundles "in-container" sounds difficult, but thanks to a handful of testing frameworks, it's actually quite easy. These frameworks are:

The first three of these testing frameworks all work pretty much the same way. After installing a collection of bundles in an OSGi framework (or frameworks) of your choosing, the test wraps itself in an on-the-fly OSGi bundle and installs itself in the framework. From within OSGi, the test is able to use and examine the bundle context, consume OSGi services, and assert that the bundles under test are behaving well.

Of the three testing frameworks listed, I tend to favor Pax Exam because it's currently the only one that is based on JUnit 4. Pax Drone is effectively deprecated in favor of Pax Exam, so unless you encounter a project that's already using it, you should disregard it. As for Spring-DM's testing support, it is nice in that it uses Spring autowiring to autowire OSGi services into a test class. But until it's based on JUnit 4, I still prefer Pax Exam.

DA-Testing is a new entry in the OSGi testing toolbox. I haven't had a chance to try it out yet, but it claims to address OSGi testing in a way that's very different than the first three testing frameworks. When I get a chance to try it out, I'll be certain to blog about it here.

OSGi doesn't have a cool name got me there. I'll concede that OSGi doesn't have a cool name like "Spring" or "Hibernate" or "Groovy". In fact, I'll even agree that "OSGi" is probably one of the most boring names ever given to a Java framework or library.

In my opinion, this is one of the worst things OSGi has going for it. I believe that a lot of the misinformation about OSGi stems from its name. It sounds complex. It sounds heavyweight. It sounds like an unpleasant medical procedure.

My apologies to the OSGi Alliance. You guys are awesome and have done some magnificent work. But the needs some work. ;-)

There are no books on OSGi

Not true! There are already a handful of OSGi books available. And with OSGi becoming a hot topic, I'm sure that there will be several more on the way.

One such book that I'd like to recommend is Modular Java. Even though I'm obviously biased toward this book, I can recommend it as a pragmatic example-driven guide to building applications with OSGi and Spring-DM.

Here are some other OSGi books that are available or will be available soon:

Of course, I really hope that you'll start your adventures in OSGi with my book.

I hope that this article has dispelled some of your doubts about OSGi. Of course, I suppose that if you're adamantly opposed to OSGi, then there's nothing I can say that will change your mind. But if you're a reasonable person who has been reluctant to look into OSGi because of what you've heard, then perhaps I've cleared things up enough for you to give it a fair look.

This is the first of several articles that I hope to post on this blog over the next several weeks (or months). I have several great articles in mind, but I have no idea where this will go. I'm going to start by covering a few of the tools that make working with OSGi easy. So keep an eye on this blog for more OSGi goodness coming soon.


Published at DZone with permission of its author, Craig Walls.

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


Ray Walker replied on Tue, 2009/04/14 - 9:18am

Well done.  You made a great argument.  One stone left unturned, however, is what is the alternative to OSGI, anyway?

Alex(JAlexoid) ... replied on Tue, 2009/04/14 - 5:08pm

First of all, nicely done.

I am an OSGi skeptic. And I think that OSGi is pushed too much in too many areas. Where OSGi does not solve anything.

OSGi is a solution looking for a problem

That is in fact a myth, but only due to the fact that some of us did get the proble. Most of people do not have the problem or did not get to a place where they would have the problem.
On the other hand, since I believe OSGi is pushed into too many areas, it is a "solution looking for a problem" for a lot of people.

 I can get modularity without OSGi

 This one shouldn't be on you myths list, since it's a fact. Even OSGi itself is written in Java.
And this is an example why I think that OSGi is pushed too much.

 So please stop making assumptions that OSGi is the tool for every Java job and, like spring before that, is the only way to go. I know you did not state that, but for some reason I get that feeling while reading the article.

Craig Walls replied on Tue, 2009/04/14 - 7:57pm in response to: Alex(JAlexoid) Panzin

Alex: You incorrectly assume that I believe that OSGi is a golden hammer and should be used in every application. Just because I speak/write enthusiastically about something should not imply any dogmatism. Yes, I really like working with OSGi (and Spring), so I am enthusiastic about them. I'd rather err on the side of enthusiasm rather than present a topic in a "'s some other technology...try it if you want...I don't really care" kinda way.

I do believe that it is a good fit for many applications, but certainly I do not believe that OSGi, Spring, Hibernate, Ruby on Rails, or ANY other framework or technology is the right fit for all projects.

So please stop making assumptions that I think that OSGi is the tool for every Java job and is the only way to go. As you said, I never stated that and that is not the message I am trying to send.

Jeroen Wenting replied on Wed, 2009/04/15 - 1:34am

Alex: You incorrectly assume that I believe that OSGi is a golden hammer and should be used in every application. Just He isn't, he's pointing out that the technology is pushed as if it were when in fact most people have no need for it. This of course is the halmark of all overhyped things in this industry, they're pushed as if they were the only thing you ever need to solve any problem when in fact they're worse than useless in the vast majority of situations.
OSGi is exactly that, an overhyped thingy that hardly anyone needs and that those who could use it have quite effective alternatives for already yet are pushed to spend vast amounts of money to adopt the new kid on the block because it's supposedly "kewl". Maybe you don't think along those lines, but many others certainly do and the constant stream of articles trying to (implicitly or explicitly) ridicule those who don't see the golden future of OSGi read not much different from yours.
As to OSGi not being new, effectively it is. Until last year hardly anyone had heard of it when suddenly, POOF, there it is and you're nobody if you don't instantly adopt it for every project. It's no different from Ruby in 2005, which also had been around for years before "exploding onto the market", or XML in 2000 or so.
Remember those days? We were told in no uncertain terms in a memo by the CEO (and this a major international financial business, the CEO was no technical person and hadn't consulted with technical people, the decision came from bankers) that EVERY project MUST use XML because "it is modern and we are a modern business therefore we must have modern tools". Though extreme it's hardly the only time I've seen decisions to adopt a hyped tool or technology made by businesspeople who didn't have a clue as to what the tech actually was, only that it was presented in business publications as being the best thing since sliced bread.
That's where I see OSGi fitting in perfectly.

Mladen Girazovski replied on Wed, 2009/04/15 - 9:26am

I think OSGi is great, still a bit green when it comes to tooling support for enterprise class applications, but that is just a matter of time.

I am an OSGi skeptic. And I think that OSGi is pushed too much in too many areas. Where OSGi does not solve anything. 

 Funily, OSGi makes your Post ( completely obsolete, or put it this way: The problem you've solved wouldn't exist if you used OSGi.

 But the OSGi Lifecycle is imho just a small goody of OSGi, i'm a big fan of the built-in support for services.



Alex(JAlexoid) ... replied on Wed, 2009/04/15 - 3:12pm in response to: Mladen Girazovski


 Funily, OSGi makes your Post ( completely obsolete, or put it this way: The problem you've solved wouldn't exist if you used OSGi.

 My main point was updates of classes on the fly. My focus was on how JVM works. OSGi on the other hand is created with the existing architecture and tooling. And my main problem would still exist, when unloading a bundle you would still have a memory leak, in case of a thread being still active in the bundle that is being unloaded.

Mladen Girazovski replied on Thu, 2009/04/16 - 3:36am

With an Activator you could stop the Thread before the Bundle is loaded, but there is a chance of memory leaks in the perm gen, due to the fact that classes that are once loaded would end up there and then cannot be removed anymore, one issue with OSGi and other Libs/Frameworks/Plattforsm that are running a long time and load classes dynamically.

Taruvai Subramaniam replied on Sun, 2009/04/19 - 1:44pm

Craig, Great post. A solution looking for a problem? Ever been up at 2 PM to bring down an entire mission critical application to fix an implementation bug? Ever wanted two versions of a service to coexist to not break the existing functionality? C'mon. I just went through a self taught beginner's obstacle course on OSGi and it is no way hard - in practice you need no more than 5 core classes to get started and if you use Spring Dm it is none. Neils' on line book that you referenced is a great intro. The real problem you should address is how to OSGi'fy web applications. Most of us have a ton of wars and it is not at all clear how OSGi and war files mix together. A post on thsi would be really appreciated.

Comment viewing options

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