Pitfalls of J2ME development

J2ME does a splendid job of promoting application portability across a diverse set of embedded devices. But some J2ME specs are vague enough that each vendor’s J2ME implementation might handle key sections of code in different ways. What follows is a rogue’s gallery of maddening variations that can stymie application portability.

* The MIDP specification doesn’t guarantee that the Display class — the object that interfaces to the screen — will be available until the midlet’s startApp() method executes. As a result, some implementations will safely permit making an instance of Display in the midlet’s constructor, whereas others will throw an exception that terminates the midlet without warning.

* Many of today’s phones have 1MB or more of RAM, exceeding the 512KB specified by the CLDC. Still, some J2ME implementations place limits on the amount of memory a midlet can use. The maximum heap size (available RAM storage for a midlet) can also vary. This means that a midlet that loads and executes on one device might not work at all on another.

* Different vendors use different typefaces to display the strings in a midlet’s messages, menus, and buttons. As a result, a carefully designed business form with control widgets can look good on one phone, while appearing nearly unreadable on another handset.

* Developers write J2ME applications with Java tools on desktop PCs. Since the handset being coded for may exist only as a limited number of prototypes — if at all — developers also typically use a simulator running on the PC to test and debug their midlets. The simulator uses the PC’s own J2SE  to execute the Java program, and occasionally it will rely too much on the J2SE’s capabilities. The result will be a midlet that runs properly on the desktop but not on the target device.