Tuesday, October 5, 2010

Minimal OSGi Systems

Every now and then the question pops up about OSGi in really tiny environments. The press release from ProSyst last week about the smallest OSGi stack caused this question to enter my inbox: "Can OSGi be used in constrained embedded solutions?"

Though OSGi is a no-brainer, the underlying question of the use of Java turns out to be harder, even after a decade where memory prices tumbled and processor speeds exploded. In this market the Bill Of Material (BOM) still is the all overriding concern, combined with 99% experience in C(++) coding in this world. Java is usually seen as a sidekick. Nice to have but real men use C(++).

The first OSGi app I worked on was the Ericsson e-box, a home gateway with 32 Mb of RAM and 2 Mb of flash. I always wanted to get rid of the Linux on it and run Java on the bare metal so we would have a single management model. I actually wrote Java implementations of DNS, DHCP, and even wrote a Java implementation of the TCP/IP stack to be able to communicate with SLIP devices! However, others in the project were experienced Linux people and found it a lot easier to just do everything with existing software. Fighting about this architecture wasted a lot of time and in the end we ended up with an ugly hybrid that was hard to manage.

Last week, a presentation from Andre Bottaro (Orange Labs/France Telecom) and IS2T on the OSGi community event seems to indicate that things are moving again. These companies developed a minimum OSGi stack in a really small device by removing Linux and running the VM on bare metal. However, though these tiny OSGi implementations are interesting exercises I must admit that I have mixed feelings. OSGi is about downloading modules, such a model requires some headroom to have value. Why waste resources to a mechanism that can only be used for trivial downloads? Java in the phone did not become very useful until Android provided an SE like class library that was sufficiently rich and the hardware had sufficient headroom to make downloadable apps feasible.

That said, I do believe that in the end OSGi is the way to go because providing new and updated functions become more and more a necessity. And there are more activities around this. Also at the community event Tim Ellison (IBM) demonstrated Apache Harmony and how the modular approach of Harmony (it uses OSGi metadata for its modules) can be used to create really small and efficient VMs. I am going to look more in Harmony because it looks like an ideal VM to run OSGi on. I also spoke to Marcel Offermans (Luminis) who is submitting a proposal to Apache for a C(++) based runtime that is based on the principles of OSGi and will work together with OSGi through the service registry. This seems even more ambitious than the Universal OSGi idea that we played with in the OSGi Alliance a few years ago.

I do hope we do see more efforts shrinking the OSGi stack like ProSyst, Luminis, Orange Labs, IS2T and many others are doing. One day we will be at a place where OSGi is a no-brainer, in small devices, including the Java part.

Peter Kriens


  1. Very interesting post. We were recently looking for updates regarding Universal OSGi for a prospective project, but we couldn't find any follow-ups.

    We discussed it a bit and we were thinking that it would be useful to be able to mix C++ and Java using the Service Registry, to create C++ programs using OSGi's principles and services but also have the C++/native code bundlelized and transparently interoperable with existing Java bundles.

    For performance reasons, we were also thinking that the system should abstract the communication layer so one would be free to use JNI or sockets.

    In this light, Marcel Offermans's proposal to Apache seems very interesting but I couldn't find it on Apache's or Luminis' website. Has the proposal been made public yet? Any link would be appreciated.

  2. Well after looking a bit further I found this proposal which seems to be what was discussed here:


  3. Hi Simon,

    That is indeed the correct proposal. One of the focus points is interoperability between Java and C.

    On the Apache Incubator mailing list there is some discussion about possible solutions for this.
    Main aspect is the use of Remote Services as abstraction for this (following the OSGi principles). This makes is possible to use JNI or sockets.

  4. I just had to code again in C++ for the handheld device and created a minimal OSGi framework where bundles are DLLs and can be started and stopped and provide services. This was just an exercise and the runtime is pretty small in footprint. Looking forward to the Apache C++ implementation of OSGi.

  5. In 2009, we developed a POSIX-compliant OSGi framework in C++ and measured considerable improvements of performance and memory consumption in comparison to common Java OSGi frameworks. There are some preliminary results on our project homepage.

    Feel free to contact me for further information.