The OSGi from a Python Perspective

Years ago, in the eighties and early nineties I spent every Wednesday night from 8 PM to 3 AM hacking with a Petr van Blokland, a long time friend. We spent our time doing a virtual tour through the computing world. We used any possible language, library, or created new ones when necessary. We even wrote our own Prolog interpreter. We developed lots of programs and had even more fun. After I moved to Sweden we kept in touch but all night hack sessions were of course no longer possible.

Yesterday he was here in Beaulieu and I introduced him to the OSGi specifications. It was kind of scary to see how great the divide has become technologically. I had to move to the PC because of Java in the late nineties, he kept on buying Macs. He fell in love with Python and I had to use, well again, Java. Though we always are much at ease with each other on the semantic level, the lack of common ground is a big challenge.

For me his visit is a wonderful opportunity to see how a highly experienced and intelligent software developer looks when he is confronted with OSGi out of the blue. The biggest hurdle is of course Java. I complained before, and will complain later, but Java is a very crufty language (try using inner classes). It is amazing how clean a Python class looks in comparison to a Java class with the same functionality.

I tried to get him hooked on Python development in Eclipse (that at least would give us a Geneva where we could further negotiate). We tried PyDev and TruStudio. Though neither plugin is bad, they still pale in comparison to the Java support in Eclipse. Eclipse is the first IDE I accepted because its support for Java development is fantastic. However, I do not think I would use Eclipse if the Java support was on par with PyDev/TruStudio.

We decided to try to make a bundle that used Jython servlets. Jython is a implementation of Python on Java. Wrapping the Jython JAR turned out to causes all kinds of packaging problems because it was using lots of external links. It was kind of sobering when you realized how arcane much of the work is you have to do to make a simple bundle. We then moved on to declarative services and there I also saw the XML with the eyes of a highly skilled Python developer.

I am the first person to know that for each piece of cruft in the declarative service XML, or Java source code, or manifest, there is a good reason. The OSGi Alliance tries to solve a problem that is very hard: make independently developed applications work together. This is much harder than a monolithic application, but we should not forget that simple things should remain simple. There is an increased awareness of this, noticing the LAMP and Ruby on rails discussions that all reflect badly on Java.

Several parties are working hard on making tools that will take any pain out of bundle development. The Eclipse team is improving their plugin development tools (a plugin is a bundle, not sure why they stick to the name plugin) and I had the pleasure of testing an SDK for the next generation mobile phones. The SDK uses a different technique than the standard Eclipse Plugin Development Environment, I actually prefer theirs over the Eclipse variation. For example, the SDK allows multiple deployment artifacts from the same bundle which Eclipse does not allow.

Both environments are just not good enough yet, I feel.  Neither has a really clear UI that guides you through the process and helps you add new features, all editors are very focused on a single artifact instead of taking a more holistic approach. Then again, Eclipse has only recently adopted the OSGi specifications and it is natural that the tooling will take a couple of iterations to get it right.

On the plus side, when we had entered all the cruft and updated our first bundle, I could see his eyes light up when he realized we never had to restart the framework to get the new functionality up and running. That part always remains sooo cool.