Personal tools
You are here: Home Developer Zone Documentation MUSIC in mobile devices phoneME, OSGi and MUSIC
Document Actions

phoneME, OSGi and MUSIC

by Jorge Lorenzo last modified 2009-09-16 10:19

Our experience to port the MUSIC middleware to phoneME (the open source Java ME)

Introduction

The reference implementation of the MUSIC middleware is built over Java SE 1.4 and OSGi R4. We are constrained to a subset of Java 1.4 so that it is possible to move the middleware to a Java ME CDC device without any change.

Java ME - phoneME

phoneME is the Sun Microsystems reference implementation of the Java ME specification under GPLv2. There are 2 different configurations:

  • phoneME Feature: An implementation of CLDC and MIDP, which are the most popular Java ME specifications available in mobile phones. However, these specifications don´t cover the MUSIC requirements.
  • phoneME Advanced: An implementation of CDC addressing more powerful mobile devices. This specification covers the MUSIC requirements and the rest of the document will refer to this configuration.

phoneME can be built from the source code which can be checked out from here. Initially, it is only required the following project components: cdc and tools. phoneME supports several operating systems and processors.

A simpler way to get a functional phoneME for Windows Mobile is by downloading the distributions created by Davy Preuveneers. This site offers very good information about this open source virtual machine. His distributions also offer some improvements like a Java console.

OSGi - Equinox and Knopflerfish

The MUSIC middleware has been implemented in Eclipse and we have used Equinox as the natural choice of an OSGi R4 framework. However, the code is independent of the OSGi framework and should work in any OSGi R4 framework.

By the moment, the MUSIC middleware has been tested in 2 different OSGi frameworks: Equinox and Knopflerfish. Although both OSGi frameworks provide different configuration methods, they are very simple.

The MUSIC middleware has some challenges (with regard to a basic OSGi configuration):

  • The use of declarative services (a R4 standard OSGi service). Declarative services use XML files and is not supported by the default configuration of Java ME.
  • Windows Mobile native libraries. The use of JNI by the OSGi framework will test the correct implementation in phoneME.
  • The eSWT API from Eclipse. We use this GUI API, which directly targets mobile devices.

Equinox

The Equinox framework requires an external XML library in order to support the declarative services bundle. This library is required in the bootclasspath:

255#"\Storage Card\pmea\bin\cvm.exe" -Xmx2m -Xbootclasspath/a:\music\xmlparser.jar
-jar "\music\org.eclipse.osgi_3.3.0.v20070530.jar" –clean

Moreover, the Equinox configuration requires to identify which Java packages are exported by the xmlparser.jar library.

osgi.bundles=org.eclipse.osgi.services_3.1.200.v20070605.jar@start,
org.eclipse.equinox.ds_1.0.0.v20070226.jar@start
org.osgi.framework.system.packages=javax.xml.parsers, org.xml.sax, org.xml.sax.helpers
eclipse.ignoreApp=true

If phoneME doesn´t provide a Java console (and the phoneME project doesn´t offer any), Java will die after approximately 10 seconds. By this reason, it is fully encouraged to use Davy's distribution (with a Java console).

We have tested successfully the support of native libraries and eSWT, and apparently the support for declarative services. However, when adding all the MUSIC bundles, we found an OS exception which killed the Java VM:

Data Abort: Thread=962e2cd0 Proc=82096e30 'cvm.exe'
AKY=00002001 PC=010c7e5c(cvmi.dll+0x00047e5c) RA=01099334(cvmi.dll+0x00019334) B VA=1c000008 FSR=00000407
Thread died with exception c00c0000005 00005 at pc 10c7e5c addr 0

We identified the origin of this problem. It is thrown when assigning some service dependencies by using declarative services. We cannot establish any pattern why some service dependencies are correctly assigned while other ones are not. Unfortunately, we couldn´t find any workaround or fix this problem in phoneME (by the moment).

Because MUSIC makes extensive use of declarative services, this phoneME bug is blocking. Equinox and phoneME are not an acceptable combination for MUSIC.

Knopflerfish

This OSGi framework appeared as a good alternative, after the failure with Equinox. The last release of the MUSIC middleware was not tested in Knopflerfish and we needed to make some changes (although Equinox and Knopflerfish implement the same standard, they don´t work in the same way). Fortunately, we verified that knopflerfish offers the same behaviour in Java SE and in phoneME.

The main differences between Equinox and Knopflerfish were:

  • Knopflerfish does not need the XML library to provide support for declarative services. The XML support is built in the bundle (with the kxml library). The system packages are not required either.
  • Knopflerfish fails in the declarative services when the cardinality of a service is 0..1. We have reported a bug. There is a very simple workaround: use a cardinality 0..n
  • Knopflerfish does not support the "WinCE" identifier as osname in the Bundle-NativeCode header. We replaced it by "WindowsCE".
  • Equinox tries to go on with the execution after an exception. However, Knopflerfish stops after any OSGi exception.
  • We identified a bizarre problem which created an infinite loop until an stack overflow. We have made a workaround for this problem, but it looks like a Knopflerfish bug.

The following figure corresponds to the Main Menu of the MUSIC GUI. The whole platform (phoneME, Knopflerfish and MUSIC middleware) was executed in a Windows Mobile emulator (versions 5, 6.0 and 6.1 of Windows Mobile) and in a PDA.

MUSIC GUI under phoneME and Knopflerfish

Although we have identified some problems, Knopflerfish is the reference OSGi framework to run MUSIC in a mobile device with phoneME.

Additional libraries

The MUSIC middleware requires some libraries which do not belong to the Java ME specification:

  • The logging library (java.util.logging package). It is the Lumberjack project; an open source implementation of the standard Java logging under LGPL license.
  • For releases before version 0.3.0 (inclusive), the Java bean library (java.beans package) is required for the MUSIC communication bundles. It was compiled from the Java SE.
  • The RegEx library (java.util.regex package) which is used for replacing the String.split() method. It was also compiled from the Java SE.

These libraries are included in the bootclasspath of phoneME.

Known problems

Some problems that we have identified with phoneME:
  • The eSWT library makes use of the AWT Component class. It is difficult to understand this dependency because eSWT wants to be a replacement to AWT. The AWT is not part of the CDC Foundation Profile, but the CDC Personal Profile includes support for AWT. We are currently using the CDC Personal Profile.
  • The MUSIC GUI, based on eSWT, displayed strange characters in some strings. It is a strange issue. It happens neither in Java SE nor in IBM WEME. The problem could be related with the newline character ("\r\n" in Windows platforms, while only "\n" in Linux and apparently phoneME).
  • There was a problem with phoneME Advanced which couldn't run on Windows Mobile 6.1, getting an error popup from the OS. This has been fixed since the build #110 of phoneME Advanced.
  • phoneME doesn't detect the language of the Windows Mobile OS, so the default locale settings are always set to English (US). However, the default language can be manually change by setting the user.language and user.country system properties in the Java code or in the command line options. For example, for the Spanish (Spain) language:

255#"\Storage Card\pmea\bin\cvm.exe" -Duser.language=es -Duser.country=ES -jar "\Storage Card\knopflerfish\framework.jar"

Performance comparison between IBM WEME (J9) and phoneME

We have done performance tests for the three possible configurations we can run: Equinox with IBM J9 and Knopflerfish with both IBM J9 and phoneME. The tests have been executed in a PDA running Windows Mobile 5 and the MUSIC middleware.

  • Comparing the performance of the two OSGi frameworks on IBM J9, the results showed that Equinox behaves better than Knopflerfish, being a bit faster. Knopflerfish seems to take more time than Equinox to load the bundles the first time the framework is launched, although it is faster in consecutive runs.
  • On the other hand, when comparing both Java Virtual Machines using Knopflerfish as OSGi framework, phoneME got better results that J9. However, as Equinox is faster than Knopflerfish, the results achieved using phoneMe / Knopflerfish are similar that those using J9 / Equinox.
  • If in the future Equinox could run over phoneME (according MUSIC needs), it would be great to compare its performance with Knopflerfish over phoneME.

As a primary conclusion, phoneME is an appropriate JVM for Java ME CDC. The fact that it is an open source implementation makes it the best option for MUSIC.

Conclusions

We have tested two different OSGi frameworks under phoneME Advanced. Equinox is not suitable for MUSIC due to critical errors, although it could be a choice for other purposes (a Java console is compulsory). Knopflerfish is the most appropriate choice for running MUSIC under phoneME.


Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: