The Ugly

Finally, we’ll cover problems with Java ME that are particularly gruesome. Usually their impact is beyond the control of the developer or the mobile phone user. Indeed, these problems are usually ultimately caused by the big players – phone carriers, software distributors and certification houses. Beware!

Code Signing Certificates

Aged or missing root security certificates on a device can mean that your signed application will not be installed.

First, some background: having a signed application means that the application is “trusted”. When the application is downloaded OTA, the certificate is checked against the device’s root certificates. If it cannot be verified against one of these, the application will not be installed. Furthermore, a user can theoretically track down the entity responsible for the application via a certificate authority which knows the entity’s true identity. Certificates must be purchased from such an authority and are fairly costly.

Signed applications enjoy privileged permission status in Java ME. For example, a trusted application could connect (or be configured to connect) to the internet without explicit user confirmation. Non-signed (or untrusted) applications theoretically do not enjoy this privilege.

Unfortunately, many phones do not have up-to-date certificates from all major certificate authorities. So when the Java ME implementation on such a phone tries to verify the application certificate against its root certificates, it may be blocked from installing.

The solution: if you can possibly get away with it, don’t certificate-sign your application. In other words, don’t use a certificate at all. Your application will not be signed but at least it will be able to be installed. Code signing is of dubious value - it often limits the number of handsets that your application will work with for little real benefit.

One final note: those sections of the Java ME specification concerning management of trusted and untrusted applications are flexible - it’s up to the implementation to decide how to implement security permissions. Furthermore, various modern mobile devices now have the ability to configure specific applications to enjoy greater-than-default privileges. For example, an untrusted application can be configured by the end user to allow http connections by default, without user confirmation.

HTTPS Certificates

Aged or missing root security certificates on a device can also mean that your signed application may not be able to successfully establish a HTTPS connection.

When making HTTPS connections, a Java ME implementation must verify the certificate of the remote site against its root certificates. But what happens next depends upon the implementation. Newer phones may allow you to override and continue (just like in your PC browser, with a message like “this site certificate cannot be verified, continue?”). Other implementations (usually older phones) simply do not allow the connection to proceed any further.

The solution to this problem? If you can get away with it, use HTTP instead of HTTPS. HTTPS may provide little real value and needlessly limit the number of handsets that your application will work with. If it is absolutely mandatory that data sent/received to the device is encrypted, it may be better to “roll your own” encryption. There are many examples and frameworks available on the internet, for example, the Bouncy Castle Lightweight API.

Carrier Locks out Functionality

Another Java ME “ugly” that we’ve seen is that some devices are tied to the phone carrier, and have functionality disabled.

A specific example that springs to mind is the BlackBerry 8700g. Normally, this device is fully capable of providing GPS (satellite positioning) co-ordinates to Java ME applications running on it - it's documented in the user guide. However, 8700g’s that I have used that were purchased through Telstra (a major Australian telecommunications company) were unable to provide this functionality. Even the GPS configuration options can no longer be found. Why? Well, you’ll have to ask them!

Java Verification

A final nasty that your application may have to undergo is a costly verification in order to make it available to the public.

Applications can be sold publicly (on the internet) by a mobile provisioning service that collects payments for distribution. Some of the major services require the application to undergo some sort of application verification before they will distribute it via their web site. This is fairly expensive, and the developer may not wish to pay for it. In that case, the provisioning service will not distribute the application.

In our opinion, whilst independent testing is definitely of value, it should not be forced. However, in the meantime, you should at least brace yourself for the possibility.