J2ME limits support for vendor-specific hardware features to accommodate variations among devices. J2ME tackles hardware variations in two ways. First, J2ME defines an abstraction layer known as a configuration, which describes the minimum hardware required to implement Java on an embedded device. The J2ME configuration that addresses resource-constrained devices such as mobile phones and low-end PDAs is the CLDC (Connected Limited Device Configuration).
Second, J2ME defines a second abstraction layer, termed a profile, that describes the device’s hardware features and defines the APIs that access them. Put another way, profiles extend a configuration to address a device’s specific hardware characteristics.
J2ME currently defines one profile for CLDC devices: the MIDP (Mobile Information Device Profile). In addition to stipulating the basic hardware requirements, the MIDP implements the APIs used to access the hardware.
It’s important to understand that a J2ME device can have only one configuration that describes the core hardware. However, multiple profiles are allowed, including the MIDP and vendor profiles that support device-specific features. A vendor can therefore quickly adapt J2ME for a new device by writing profiles for it.
Besides interfaces, the MIDP describes the characteristics of a J2ME application, known as a midlet. Midlets are taxonomically similar to Java applets, the major difference being that a midlet can download data but not additional code through the connection. The end result is that a midlet has the potential to run unaltered on any J2ME-enabled device. Furthermore, because J2ME profiles define the interface, the appearance and behavior of the midlet on different devices is nearly identical. J2ME thus holds out the promise of becoming a universal front-end for client applications that can run on any mobile device.
The astute reader will have no doubt noticed the words “potential” and “nearly” in that last paragraph. Let’s face it: A few limitations in J2ME can hamper application portability. To begin with, subtle variations in each vendor’s J2ME implementation can cause incompatibilities.
Another issue is that if an API doesn’t exist for a specific device feature, you can’t use that feature at all. J2ME does specify optional standards, such as the MMAPI Mobile Media API, which provides support for audio playback and streamed video. Unfortunately, a developer can’t rely on an optional standard being available on every device.
However, J2ME is constantly evolving to address these concerns. In November 2002, the Java Community Process (JCP) released a significant revision to the MIDP specification. Called MIDP 2.0, it adds mission-critical APIs that support secure network connections (via HTTPS) and implements permissions with digital signatures to support trusted code. The specification also provides improved UI elements that offer enhanced form layout for business applications.
Unlike optional standards, a device that uses MIDP 2.0 must implement all the APIs that it describes, thus ensuring their availability to a program. Handsets that support the MIDP 2.0 specification should appear on the market later this year.
Down the road, the JCP proposes a new JTWI (Java Technology for the Wireless Industry) specification. In JTWI, a number of optional J2ME APIs — such as MMAPI and WMA (Wireless Messaging APIs) — become required services.
Even in its current state, J2ME offers developers the ability to write once and deploy a business application across the wide range of wireless gear currently available. J2ME’s abstraction layers also provide a hedge against vendor lock-in, and they help cope with the rapid changes in today’s wireless devices. Developers may have to craft the midlet’s interface to address the lowest-common-denominator display, but that’s a small price to pay compared with writing a custom client application for each device the corporation owns.
Read more about networking in InfoWorld's Networking Channel.