When modularity comes down to OSGi

Last week I attended a tech talk by Christian Schlichtherle, organized by Euro Staff in Berlin. The talk was about modularity and its different forms in software development. Christian talked about packages, libraries, APIs, dependency management and – as always when it comes down to modularity – about OSGi.

Every time somebody is talking about OSGi I get this tiny pain in my stomach. OSGi is a really great idea and a lot of people are working with it for many years right now. That’s cool! But I still have some questions about this…

Who wants to install code during run time on a server?

Let’s start with my biggest point of criticism. OSGi has two main points:

  • OSGi (maybe) solves the class path hell (we will come to this later)
  • OSGi introduces modularity during run time for Java software

But really – who builds software with a highly static language such as Java but then installs code during run time on his production environment!? Maybe I just don’t know the use-case, but every company I saw so far is looking for a stable server architecture. They want to deploy something in their test environment, then go to staging and finally do a green-blue-deployment. They don’t want to throw some new software in and let itself install it. And if they would do so, I would wonder how they deal with open user sessions, with buggy updates which breaks the system, with security and so on. In my opinion there are only very few cases where you really need and want modularity on the server.

OSGi is solving the class path hell!

It’s often said that OSGi is solving the class path hell. And when somebody is saying this, he comes up with the diamond problem:

Some package A needs a package B and C. B and C need a package D but in two different version. And you are screwed!

OSGi solves this problem, because every package will get its own class loader and every Java class is not only identified by its name but also by it class loaded. This makes it possible to load the same class in different version for package B and C. Problem solved!

But what happens when package B and C are returning objects from package D? Let’s make some stupid example: Package D contains a model: Person.class, Address.class. Package B and C are different factory strategies for this model. Package B reads data from a web service and package C from a local file. And package A is using both of them:

The problem with this code is that it looks perfectly fine and will compile, too. But it will fail on run time with a class cast exception! Why? Because User.class from package B was loaded with a different class loader as User.class from package C. So for Java, those are two different classes!

To solve this problem in OSGi you would write a service with an interface in package B and C, describe it in XML and wire it in package A. You would expose those services explicitly and create bunch of XML. Then you would package everything with an OSGi compatible manifest, assign version number to each bundle, re-pack third party libraries to OSGi bundles too, define a start-up order for the bundles, load an OSGi run time environment and then – a couple of hours later – you really solved the diamond problem.


I think solving the class path hell in OSGi means to introduce a class loader and bundle hell instead. In pure Java it’s simple: if something is on the class path, you can use it. In OSGi, this is more complicated and if you miss to strictly use OSGi services to decouple you software you will end up with a highly coupled bunch of bundles which might throw class cast exception because you still cannot user version 1.5 and version 2 at the same time.

Best regards,

Who is using OSGi?

Who is using OSGi? If you take a look http://www.osgi.org/About/Members you will see more than a hundred members of the the OSGi Alliance and a lot of big players just like IBM or Oracle. But lets do a little investigation with Google Trends on our own.

Google Trends

Google Trends is a service where you can search for a particular key word and get a time line. The time line shows you when the key word was search and how many requests have been made. That is a great way to estimate how popular a certain technology is at a time. Google will also show you where the search requests have been made – and that is where we start.

OSGi in Google Trends

If we search for “OSGi” on Google Trends we will see a chart just like the one shown below. As we can see, OSGi is somehow over its peak and the interest in the technology is decreasing since a couple of years.

But even more interesting is the map which shows where the search requests have been made. As we can see, most requests came from China. On the fourth place is Germany.

If we take a closer look on Germany, we see that most requests come from the south of Germany.

But we can even get more specific and view the exact cities. It is a little bit hard to see in the chart, but you can click on the link at the bottom to see the full report. You will see Walldorf, Karlsruhe and Stuttgart on top. So what? Well, in Walldorf, there is one big player who is not on the list of the OSGi Alliance: SAP.

We can do the very same with the USA and we will end up in California and Redwood City, where companies like Oracle and Informatica are located.

Best regards,

Begin of my master thesis about OSGi and PaaS providers

My studies go into the final round – since the first of February I work on my master thesis about (enterprise) OSGi applications and PaaS providers in the cloud. I evaluate an existing OSGi server application and try to migrate it to a PaaS provider. My deadline is in the mid of July 2014.

Photo by Kevin Dooley / http://www.flickr.com/photos/pagedooley/2511369048/

Photo by Kevin Dooley / http://www.flickr.com/photos/pagedooley/2511369048

Right now I am doing my literature studies and try to get an overview about the topic. I don’t know the exact direction of my thesis yet, but I can figure out some problems along the road like databases, scalability, dependencies and deployment. And I think some more will show up soon.

I write my thesis by Informatica/Heiler in Stuttgart. I will blog about it from time to time under /tag/cloud.

Best regards,

Review: Modular Cloud Apps with OSGi

Currently, I am doing my literature studies for my master thesis about OSGi and PaaS. One of the first books I read was Modular Cloud Apps with OSGi from Paul Baker and Bert Ertman published by O’Reilly. Here is what I think about it. Maybe it is a little bit ironic sometimes, but I hope you get the point.


Far more OSGi than Cloud

Modular Cloud Apps with OSGi is much more over OSGi than cloud. You will read about bundles, Bndtools, plugins and all the other (standard) OSGi stuff all over the book. The terms IaaS, PaaS and SaaS are explained on page 152 of 190 (including references and index). All stuff before is just OSGi. The only real cloud technology in the book is Amazon’s AutoScaling


As I said, the only “cloud” chapter in the whole book is the one about deployment (~8 pages). The author explains how you can deploy nodes with Amazon’s AutoScaling and the Apache ACE provisioning server. An examples as well as some scripts are provided. And by the way, Paul Bakker, the author of the book is a contributer of Apache ACE, which brings us to another topic called Amdatu.


You will find one term over and over in the book: Amdatu. Amdatu is a Java OSGi framework to build (modular) cloud applications. And guess what? It is build by one of the authors of the book, Paul Bakker! This could be the reason why Amdatu seams to be the answer for everything. How should we implement authentication? With the Amdatu token provider! And what about a REST API? Yeah, Amdatu has all the libraries packed in some OSGi bundles! And ever thought about some documentation? Amdatu has already repacked the Swagger framework! And don’t forget Amdatu Social, Amdatu Mongo and all the other stuff reinventing the wheel for you while talking about modularity to help you to don’t reinvent the wheel. Also consider to not use standard frameworks like Spring, Amdatu has a more modular solution! But try to search Amdatu on Google Trends

The world is not ready for OSGi

The world is still not ready for OSGi! After reading the book you get a notion that every existing Java framework is not modular enough and the only solution is to repack them all. None shall pass.

Riding the cloud wave

The book is really good to learn something about OSGi and maybe to get some insights into SOA. You will learn what bundles are, how provisioning can be done and what REST is. But the cloud part is really weak. The book does not cover any cloud system, any cloud service or any cloud SDK/API. What a pity. Modular Apps with OSGi would have been a much better title, but cloud sells.


By the way, there is an excellent video on YouTube by the authors of the book. IMHO the video explains much better how to build cloud apps with Amdatu and OSGi than the book. Especially the part about Apache ACE becomes very clear. Take a look:

Best regards,