Wednesday, June 10, 2009

OSGi Case Studies == Pain?

During JavaOne Atlassian presented a case study of OSGi and offered Atlassian Plugins. The presentation was very dualistic. One one side it was very positive towards OSGi but it also was (overly) critical, mostly because they ran in many problems with legacy code. This caused reactions, like the blog OSGi Case Studies == Pain.

As the OSGi evangelist I would probably say it a bit sweeter, but in principle the blog is right: don't use OSGi unless the benefit offsets the cost. Which should of course be true for everything you do. If you have a legacy application of a couple of thousands lines of code, don't bother with OSGi, it will probably be just in your way at its current incarnation.

The reason for the pain is not some unnecessary complexity in OSGi, on the contrary, with less than 30 well documented classes OSGi is actually quite simple in contrast with almost any other API I know. However, enforced modularity is painful because it confronts you with all the entanglements in your code, and even worse, the hacks and shortcuts in the libraries you use. Strong modularity puts your code in a straightjacket, and often that is no fun when you have legacy code that enjoys the anarchy of the Java class path.

Is that pain worth it? Well, both industry and science seems to have clear consensus that modularity provides lots of benefits for large applications. All the major Java app servers are not based on OSGi because they think it is fancy (notice that most do not provide the API to application developers), the sheer size of these systems just require strong modularity to survive their evolution.

Eli Whitney was one of the key drivers of the industrial revolution because he had the idea of interchangeable parts for guns. However, it took the effort of many others and long years before this simple idea could finally be put into practice. During that transition, the skilled gun making craftsmen of those days poked fun of the whole idea and told each other jokes about how interchangeable parts weren't. I think OSGi is that simple idea of interchangeable parts for software. It is a very, very hard problem, but I am convinced it is worth pursuing. Once you have experienced how you can mix and match bundles to construct a large part of an application it is imposible to ever go back.

OSGi is by far the furthest along this idea but I am the first to admit we're not there. It will require more time and effort of many, including you, to modularize our codebases and develop the tools to simplify that process. So yes, it can be a pain to move legacy code towards strong modularity but I am sure that when your applications are big enough the gain will more than compensate the pain. As many can already testify, including Atlassian.

Peter Kriens


  1. Don Brown clarified the presentation a little bit, saying that the slides weren't the whole story.

  2. The pain isn't with the complexity of the API.

    OSGi would be a lot easier if the containers supported deployment in a non-proprietary way.

  3. We need to do more to make it easier to migrate to OSGi, and in my opinion that means making it possible to run legacy code in an OSGi container without changes.

    We need to think of migration to modularity as a long-term process based on the refactoring of always runnable code. The problem is that potential OSGi developers currently need to make a lot of changes just to get their app in a runnable state, and many will not think this is worth the effort.

    I recently wrote about potential solutions to this problem, and I'd be interested to hear what you think.

    --- Patrick

  4. @patrick: I think this blogs try to make the point that making your code (and its libs) modular is the painful part. I do not think there are any tools or ways to automate that :-( Any tools around, and I include bnd, are just putting lipstick on a pig when the underlying code is not modular.

    Peter Kriens

  5. The biggest chance and also problem with osgi is that you do not describe exact dependencies anymore. When you only import packages and require some minimal or maximal version it means that the developer of the library has to do very good version management. If he changes an api and does not change the major number it can affect an already deployed application.
    With maven you already have the same problems it compile time but with osgi it can crash at runtime. We need a whole set of new tools for this problem.

  6. I fully agree with Christian; my view is that to have a good run-time stability/consistency we need versioning sorted out quite well. Among other things this means a scheme that is universally applied and tools that generate always correct id-s. I'll touch this issue during my talk at the upcoming OSGi DevCon in Zurich (Monday 22nd June).