ecause Java is theoretically portable, people assume that when you develop a Java mobile application, it should run correctly on all Java-enabled devices. Like most things theoretical, this just doesn't work in the real world. During the short life of J2ME mobile applications, many developers have expressed concerns that interoperability problems are not going to be solved so easily by new initiatives like MIDP 2.0 or JTWI.

The reality is that J2ME may be globally portable but J2ME applications are not. This means that byte-code runs correctly on all Java handsets but the behavior of an application must be adapted for almost each handset. There are 1200 mobile devices, all of which have different capabilities, support various Java platforms—including MIDP, and support optional APIs and optional parts of APIs. Not to mention that each of these implementations has its own unique set of bugs (click here to see a demonstration of this fragmentation of device characteristics and features).

The result of this is that, in a typical development cycle, porting and testing can consume from 40 to 80 percent of your time, depending on your level of experience and on the number of devices you need to support.

Testing your ported mobile applications on real mobile phones isn't always easy. A good emulator should reproduce all the bugs of the real device, but emulators don't always exist and when they do, they're far from reliable.

Bugs are another difficulty—you either need resolve bugs in your source code or deactivate the problem features, all of which can be different depending on the firmware version. Manufacturers face difficulties when there are bugs in their virtual machines. This causes problems with the integration of the VM in the handset at the hardware level.

Mobile operators need to control the quality of the distributed midlets, because low-quality midlets affect operator service. Operators also need to transpose older, more successful midlets for newer device models and for wider availability. This is why developers have to be able to port their applications to these new devices quickly.

Do You Need Automatic Porting?
The number of devices your application is able to support is the main question—and the one that most effects your return on investment. Automating your porting has many benefits:

• It reduces the time to market and enables J2ME prototypes.
• It automates tedious tasks.
• It allows you to focus on your application logic instead of various device specs.
• It allows you to produce optimized applications to each device.

First, you'll need take into account the specificities of each device model. Your application should use optional features whenever available. Table 1 shows some examples of what functionalities your application should support depending on the device.

If the device …	… Your application should
supports sounds	play sounds
supports alpha-blending	display the menu by varying opacity
has strong .jar file size limitations	remove not mandatory images
supports fullscreen	use fullscreen
has enough heap memory and supports large .jar file sizes	use optional features like bitmap fonts
supports camera control	be able to customize games using snapshots taken with the camera
supports Bluetooth	use the SMS or HTTP connections to communicate with others users (ie. chat, etc.)
supports SMS	use it to pay to activate the current application
supports PDAP	use it to access images in an internal gallery
can initiate a phone call	make phone calls
supports running applications in background	run applications in the background

Table 1: Examples of the specificities of device models