OSGi/JSR Update

One of the largest chunks of the Mobile Platform release is the Dmt Admin service. This service provides an API to the device management tree. Nodes in this tree can have a value (they are called leaf nodes) or they can be the parent of other nodes (they are called interior nodes). Each node has associated meta data that provides guidance of how to use the node. Nodes are mapped to registers, persistent storage, software unit, or anything that can receive and provide information in the device.

We have closely followed the OMA Device Management model while developing the API. This does not mean the Dmt Admin service is limited to OMA DM. The Dmt Admin service can be used via any possible protocol. However, the OMA DM protocol maps perfectly to the Dmt Admin concepts.

Interestingly, we were not alone in developing an API for device management. In the parallel universe of JCP, there was JSR 246. For reasons nobody has been able to explain to me, JSR 246 was chartered with developing a OMA DM API for CLDC; JSR 232/OSGi is a CDC API. In the future we will obviously add a J2SE and J2EE version as well, and why not a .NET when we are at it. Ok, serious. Having two similar APIs for a single problem is ridiculous. Fortunately, the JSR 246 and OSGi Mobile expert groups sat down to work out their differences. This was not too hard because the JSR 246 had started with the OSGi based API but had then taken its own route. This merge is good news.

Maybe this can cooperation between JCP and OSGi for this problem can set the tone for future work because there are more bizarre things going on. JSR 277 Modularity is extremely quiet, despite of several promises of intermediate reports. The rumors I am hearing are not pointing out a lot of progress. What happens in JSR 277 is crucial for OSGi and all its adopters. We have invested 7 years and countless hours to develop a modularity layer that is finding adoption by many companies and open source projects.

There is something seriously wrong with JCP when the stakeholders have no opportunity to participate in a specification in which they have such a high stake. Worse, there is not even a good opportunity to raise issues with the JCP because there is not even a mailing list (when I asked about this, they said there were technical problems!). Even executive members seem to be more or less powerless because the agenda of meetings is only set by Sun. The ones I have spoken all grumble but seem more or less powerless.

Anyway, at least in JSR 246 we have made progress. Let us see how we can work with JSR 248 and JSR 249 which will also be critical for the success of JSR 232. The 248 and 249 JSRs specify the profiles for mobile devices based on CLDC and CDC. It is paramount that they permit the use of JSR 232/OSGi on mobile devices. Alas, the secrecy of the work being done in JCP makes it hard if not impossible to judge what is happening there.

For the good of the industry, SUN should open up the JCP so that outsiders can at least observe what is going on instead of being confronted with a complete result. I chose Java in 1995 because I wanted an alternative to Microsoft. I had no idea I was helping to create a successor.

Peter Kriens
posted by Peter @ Thursday, January 12, 2006