Wednesday, March 12, 2008

A quick comparison of MIDP3 and OSGi

A number of times I heard the argument, that JSR-271 MIDP 3.0 provides a solution for everything that OSGi provides, maybe less elegantly, so JSR-232 is not needed. It had a been a while since I last read JSR-271, so now I took the time and read the Public Review version of the specification. So here I provide a brief comparison of the two specifications. I don't want to claim that OSGi is better or worse than MIDP 3. It would be comparing apples to peaches, they are meant for different purposes. I just want to prove, that OSGi does add value, even to MIDP 3, so it makes sense to use them together. And the added value is not only by providing more elegance.

Device Management

I mention Device Management only briefly, as this is clearly the apples to peaches category. A significant part of JSR-232 is dealing with operational management of the components throughout their complete lifecycle, from deployment to removal. I think operational management is a very important added value. It is easy to see that manageability of software assets is essential for enterprise applications, where the financial success of a company can directly depend on the proper operation of an applications. However, it is equally important for mobile operators to reduce their customer care costs and improve customer satisfaction. Just consider the recent release of Sprint Titan platform.

MIDP 3 on the other hand hardly contains anything related to management of the applications. The only exception is the over the air provisioning of MIDlets. So there is a lot of value to add here.

Component Platform

As remote management is so clearly out of the scope of MIDP 3, people were referring to the component model of the two platforms when they said that MIDP3 has everything that OSGi has.

In earlier releases, MIDlets used to be monolithic applications running in isolated silos. There was no interaction between MIDlets and it wasn't possible to share code either, well except by copying the classes from one version to the other. MIDP 3 introduced some new concept to improve in these ares:

  • Liblets are class library like packages, which can be used to share code between MIDlet suites
  • Inter Midlet Communication using a special ICM protocol
  • Autostart MIDlets are MIDlets that the AMS must start when the device starts and restart if they fail.
These are the technologies that now form the "MIDP 3 component platform". Let's see how these realize some common characteristics of such platforms.


One characteristic of a module system is encapsulation, the ability of a component to hide the specifics of its implementation and selectively export its internals. OSGi bundles can decide on Java package level which classes to make available for other components. Liblets are completely transparent, all resources in a Liblet are available for its clients. Additionally, the Liblet is executed in the namespace of the MIDlet using it - together with all other dependent Liblets as well - and it is the responsibility of the Liblet and MIDlet developers to avoid name collisions between these entities.

Dependency Management

In OSGi, the dependencies are expressed in terms of Java packages and their versions. The dependencies are resolved at runtime, the whole system is so dynamic that the components can be updated even at runtime, without breaking the operation of the platform.

MIDlet suites have to express their dependencies on Liblets in the MIDlet descriptor and manifest. During the installation, these dependencies are recursively resolved, and if the resolution succeeds, all required Liblets and the MIDlet suite will be installed.

OK, MIDP 3 is "less elegant" than OSGi. But it still handles dependencies, doesn't it? Well, there is a "small" difference between OSGi and MIDP 3 dependency model. As I said, OSGi uses package names and versions to express dependencies. MIDP 3 uses Liblet name, vendor name, version and the SHA-1 hash of the Liblet package as the means of expressing dependencies.

What does this mean? All dependencies refer to an exact compilation of a a particular Liblet, as sometime even a recompilation gives slightly different byte code, which results in a completely different hash value. So if you want to update a Liblet on a device, you have to update all Liblets and MIDlets that depend on it. Even if you corrected a small bug or just lost the binary copy of the earlier compilation.

So yes, literally speaking there is dependency handling, but the true purpose of managing dependencies - i.e. the ability to mix and match components while ensuring their proper interoperability - is completely lost, due to the rigid mechanism, which prevents any mixing.

Besides, this solution greatly reduces the value of Liblets in decomposition as well. You cannot change a Liblet individually. If there is a bug in a Liblet, you have to redeploy all dependent applications and Liblets to fix it.

Security Model

In OSGi, each bundle has its own associated permissions, its own protection domain. Bundles coming from a trusted source can obtain high privileges and expose services for less trusted components in a controlled manner. For example the permission to load native code should not be available for all components. But a component from trusted source can expose a native service to all other components by wrapping it with a Java interface. The clients of this interface will not need the permission to load any native code to use this service. This enables the creation of bundles that extend the platform with new services.

MIDP 3 Liblets are executed in the protection domain of their client MIDlets, which means that the code in the Liblet is executed with the exact same privileges as the host MIDlet. Therefore a Liblet cannot do anything that the host MIDlet could not do either.

Component Interactions

OSGi components interact via services. Services can be found via the central service registry, where any component can register its services. A service is then accessed via method simple calls and arbitrary data types can be used as parameters.

Apart from shared files or shared databases, MIDlets can interact via events. MIDP 3 defined an eventing mechanism, which allows MIDlets to publish and listen to events. An event can carry a single scalar or String value and an additional byte array as data.

I guess it's pretty clear which mechanism is more developer-friendly.


I have no problem with MIDP 3. Honestly! I do respect the work they did in the expert group and I understand how heavy burden the backwards compatibility requirement with MIDP 2.1 and CLDC was. I just wanted to point out that JSR-232 can add value, even to MIDP 3. And this value is not only marginal improvement of some existing features of MIDP 3. The means provided by MIDP 3 to decompose and manage complex applications are not suitable. JSR-232 can complement these weaknesses by its well-established component model and rich features in operational management.


Android app developers said...

Great post.I like your blog creativity.This is one of the thoughtful post.

rize wordpress said...

Android SDK tools compile the code into android package, an archives file with an .APK extension. All code into .APK file is considered an Android Development, and is the file that uses to install the program.