Increasingly, cell phone and PDA users are looking to have their information and applications available on their handheld devices. If you’re a Java developer, this means that you may need to learn how to write portable code, that is, to program handhelds, in the next year or so. A recent Gartner study indicated that Java will play a pivotal role in rapidly emerging mobile and wireless AD markets. Furthermore, by 2004, Gartner predicts (with a .70 probability) that Java 2 Micro Edition (J2ME) will become a dominant development platform for handheld devices.

In the long term, you can expect that additional types of devices will become available, each with specialized (and limited, when compared to, say, a PC) functionality and display capabilities. Let’s take a look at the J2ME spec, the likely way you will be developing for this new platform.

The basics
With J2ME, Sun has basically extended Java for use in programming the devices that are anticipated to become increasingly customizable in the future. Thinking beyond cell phones and PDAs, it’s conceivable that before long, you’ll be able to download a simple program to tailor common household appliances to your preferences. This new programming niche, while currently in its infancy, stands to help refine the way we use many things, from toasters to home security devices to other common items we have yet to consider.

It seems clear that programming for handhelds will require both versatility and simplicity. Versatility will be necessary to allow programming a large number of devices that have different uses. Simplicity will be required to pare down the user interface to its skeleton so it can function on a potentially limited physical interface. Beyond that, we all know how quickly the course of an emerging technology changes, so programming for handhelds should be tackled in a way that allows the applications to evolve with technology.

Because it is Java technology, the J2ME spec is obliged to be flexible, and it is. It includes three layers that stack on the host operating system of a device: the configuration layer, the profile layer, and the virtual machine. Together, these layers allow development for a variety of devices.

The configuration layer
The configuration layer defines the lowest common denominator, or basic functionality, on and for a set of devices. It includes Java language and virtual machine definitions and a supporting set of class libraries and APIs. Two configurations are defined, although additional ones may be defined if needed. The current configurations are:

  • Connected Device Configuration (CDC): This is for “shared, fixed connected devices,” like automobile navigation systems and Internet TVs, which usually have high bandwidth network connections and offer a larger set of display capabilities.
  • Connected Limited Device Configuration (CLDC): This consists of “personal, mobile connected information devices,” which typically have limited user interfaces and low memory. The CDC is actually a superset of the CLDC, and Sun, itself, says the line dividing products into these configurations is fuzzy.

The CDC and CLDC inherit functionality from J2SE, but as you would expect due to the size constraints of mobile devices, they’re not nearly as robust. They do include elements of java.net, java.io, java.util, java.lang, and java.microedition.io. You can also customize with CDC and CLDC by introducing features that aren’t part of J2SE. The CLDC configuration is designed to handle networking, security, internationalization, and the core Java libraries. Support for floating-point data types (float and double) is not included, and there is limited error handling.

The profile layer
The profile layer outlines the unique requirements of each device within a configuration. For example, for each device included in the CLDC configuration set—say, a POS terminal and a pager—separate profiles would be defined. Profiles include APIs and class libraries and are used to address event handling, the user interface, and application installation and launching. Currently, the Mobile Information Device Profile (MIDP) is defined for cell phones and pagers and, when combined with the CLDC, provides a full Java runtime environment. The MIDP extends the connectivity support provided by the CLDC with specific functionality for the GenericConnection framework, which can be used to support client/server networks. More info on MIDP is available from Sun.

As an example of a J2ME application, Sun has released a white paper set that includes Smart Ticket, a demo app built using J2ME and J2EE.

The virtual machine
With the K Virtual Machine (KVM), Sun is attempting to provide the minimal core Java language set that offers maximum flexibility for devices with limited resources and little memory. Built in the C programming language for portability, KVM implementation requires at least 128 KB (but 256 KB is preferable) to run the virtual machine, the class libraries defined in the configuration, and the application itself. The KVM component is closely related to the CLDC configuration, as neither currently has another counterpart to run with. However, it’s expected that over time, more virtual machines and other configurations will be implemented. Limitations in adherence to the JVM spec include those listed in the explanation of CLDC above; others, as documented by Sun, include no support for Java Native interface (JNI), no user-defined Java-level class loaders, no thread groups or daemon threads, no finalization of class instances, and no weak references.

Be prepared
Millions of handhelds that are already J2ME-enabled have been shipped. And as demand increases, developers will need to pursue in-depth knowledge of this evolving technology. Certainly, programming for these smaller portable devices will include a learning curve. Developers will need to learn how to work with simpler interfaces, while customers figure out what they want and are willing to pay for on these new devices. Meanwhile, you can get ready by learning more about this growing user environment.

Are there applications in your organization that can go mobile?

What types of apps are you likely to be porting to a mobile platform? What challenges are you anticipating? Send us an e-mail with your thoughts and concerns or post a comment below.