vufone blog

Almost a decade ago, in the JavaOne conference of 1999, Sun Microsystems introduced a new Java Virtual Machine for small-memory, limited-resource, connected devices, such as mobile phones. The first K Virtual Machine (KVM) was demonstrated on Palm OS, as a proof of concept. Since then, it has become part of the Java 2 Micro Edition (J2ME) platform, or as it is called now, Java ME. Today, Java ME is the most common application platform for mobile devices, including most GSM and iDEN phones and some CDMA phones, such as those that are provided by Sprint in the US. The importance of Java ME is that it has opened mass-market phones that are running embedded operating systems to third party application developers. However, the main challenge now is how to develop an application that would be portable across different devices, seamlessly.

Although most mobile phones today support Java ME, it doesn’t ensure any compatibility between them. Realizing the different capabilities of different devices, Java ME is not a monolithic platform. A specific Java ME runtime environment is defined by 3 layers: configuration, profile and optional APIs. Most mobile phones support the Connected Limited Device Configuration (CLDC). On top of that you will usually find the Mobile Information Device Profile (MIDP). But, when it comes to optional APIs, the number of combinations is enormous. Each API is defined in a specific Java Specification Request (JSR), which is denoted by a number. Common examples are JSR-75, which includes the PIM API and the File Connection API, JSR-82, which specifies the Bluetooth API, and JSR-120, which specifies the Wireless Messaging API. Many applications require one or more optional APIs. The vufone mobile application, for example, requires JSR-75 and JSR-120.

Even if you have a mobile phone that has all the required APIs, it is still not enough in terms of compatibility. There are many different implementations of Java ME. Although they implement the APIs that are defined by the relevant specifications, there are still different interpretations of the semantics behind these APIs, and sometimes even bugs in the implementation. In many cases, the specifications define the API as a framework, but leave the definition of the actual resources behind it to the implementation. For example, the PIM API, which is specified by JSR-75, provides access to contacts, calendar and tasks. However, it allows each implementation to support different PIM categories and any subset of fields per PIM item.

The most painful aspect of deploying Java ME applications is the issue of signatures. There are several operations which require permissions, such as accessing the network, reading and writing user data, sending SMS, and others. APIs that provide access to these operations are restricted and the application will be allowed to use them only if the application manager grants the relevant permissions. How does the application manager decide which permissions to grant? This is the tricky part…

An unsigned MIDP application (MIDlet) is considered untrusted. If the application is signed, it can be mapped to 3 protection domains: third party, operator and manufacturer. If the signature is valid and is authenticated against a certain root certificate that resides on the device, then the application will be assigned to the corresponding protection domain. Finally, the security policy specifies which permissions are granted to each domain. This policy is set by the manufacturer or operator and is completely hidden from the developer. The outcome is that in many cases it is impossible to know in advance which signature is required until you actually try it. Furthermore, some devices allow only applications in the operator or manufacturer domain to access certain operations. It means that as a third party developer you may not be able to install your application on these phones.

To summarize, Java Micro Edition has become the most common application platform for mobile devices in the last decade. However it still suffers from some major deficiencies that create pitfalls for application developers. We hope that these issues will be addressed by future implementations of Java ME.