The Java Technology for the Wireless Industry specification (JTWI) encompasses a standard set of J2ME APIs for mobile device development that is being widely adopted by mobile telephone service providers, making it an important platform for Java developers.

Its core component, the Mobile Information Device Profile (MIDP), provides a number of specialized libraries for multimedia and games development; however, its underlying subset of general purpose Java classes is strictly limited. In addition, support for persistence via the Record Management System is relatively poor. This raises an important question: Is JTWI a realistic application development tool or is it only good for games and other software trivia?

In this article, we try to answer this question by exploring the viability of MIDP as a tool for nontrivial application development. An enterprise application that includes mobile components might reasonably expect to devolve some of its business processes and data management to mobile devices. Our chosen example, which considers both of these aspects, is a proposed implementation of the Java Data Objects (JDO) specification. This includes a number of interesting features that highlight the constraints of working with J2ME APIs for limited devices. We describe the issues around the development of such an implementation and the limitations that MIDP imposes, suggest some useful workarounds and architectural options, and finally draw some conclusions about the usefulness of JTWI as a set of APIs for serious application development.

Introduction
Handheld computers, such as the Pocket PC and the Palm, can support reasonably complete Java Application Programming Interface (API) sets that can be used to develop serious enterprise applications. However, smaller devices, such as mobile telephones, only support Java APIs that have been significantly reduced to work within the confines of limited hardware. There is no support for the types of persistence mechanisms that we have come to expect on larger Java platforms. The question we address in this article is whether the mobile telephone is a viable platform yet for serious business or scientific applications that need to store and process data locally and that expect the services of a reasonably rich set of Java APIs.

To date, we have seen considerable development in areas such as mobile games development, but more serious business and scientific applications will need to be developed if JTWI is to be a useful component of enterprise software systems. Since such systems are likely to require considerable support for persistence, we focus on the JDO specification and examine some potential issues that arise when attempting to implement this specification using MIDP. We extrapolate from this analysis to assess the general usefulness of MIDP as a general purpose application programming platform. We also look at how MIDP devices fit into larger distributed architectures that can mitigate the limitations of mobile telephones as Java application platforms.

The Java 2 Micro Edition (J2ME)
To cater to a wide range of small devices and application requirements, the J2ME architecture (see Figure 1) provides multiple configuration and profile layers that overlay the specialized Java Virtual Machine (JVM) and operating system. Configurations define the minimum set of available JVM features and class libraries for a specific category of device and are hardware focused; profiles define the set of APIs available for a particular market category of devices and are software focused.

J2ME configurations specify the minimum requirements for memory, Java language features, JVM support, and runtime libraries. There are two standard J2ME configurations: the Connected Device Configuration (CDC) and the Connected Limited Device Configuration (CLDC). For the smallest portable devices, such as mobile telephones, the standard configuration is the CLDC. This configuration requires a very small virtual machine, such as Sun's KVM (Kilobyte Virtual Machine) or CLDC HotSpot Implementation, with footprints of only about 50-80K. These virtual machines don't have to comply with the full JVM specification, nor do they have to support the complete Java language specification. API support is limited to a selection of classes from a few packages from the Java 2 Standard Edition (J2SE), plus the Generic Connection Framework (GCF), comprising a hierarchy of connection interfaces (and the Connector factory class) that are intended to provide a generic way of expressing operations on connections regardless of the actual protocol.

Java Technology for the Wireless Industry
The key goal of the JTWI specification is "to minimize API fragmentation in the mobile phone device market, and to deliver a predictable, clear specification for device manufacturers, operators, and application developers" (http://jcp.org/aboutJava/communityprocess/final/jsr185/index.html).

Thus, we can reasonably expect the next generation of Java-enabled telephones to support these technologies. The specifications included within JTWI are:

• Mandatory specifications:
  -Mobile Information Device Protocol (MIDP) 2.0
  -Wireless Messaging API (WMA) 1.1
• Optional specification:
  -Mobile Media API (MMAPI) 1.1
• Minimum configuration on which JTWI is built:
  -Connected Limited Device Configuration (CLDC) 1.0

From an application development perspective, the most important API is MIDP (and by implication the CLDC upon which it builds), since these are the APIs that provide a subset of the standard Java packages found in the Java 2 Standard Edition, along with additional APIs specifically tailored for mobile development. One important issue with JTWI is that it mandates only CLDC 1.0, not CLDC 1.1, which, as we will see, introduced some important new features.

The Mobile Information Device Profile
The MIDP is one of two profiles (the other being the Information Module Profile) that works on top of the CLDC. It provides graphical interfaces for interactive applications and is the standard Java profile for mobile telephone development under the JTWI specification.

There are seven packages containing the additional classes and interfaces of the MIDP, providing user interface features at two levels of portability, sound support, certificate-based authentication, persistence, and the MIDlet framework for deploying classes into a MIDP environment. There are also extra classes in the javax.microedition.io and java.util packages.

The sum of APIs available to a MIDP developer will be the combined set of classes in the CLDC and MIDP. Figure 1 summarizes the relationships between the relevant configuration and profile APIs and the underlying J2ME JVM.

What Is Missing from MIDP?
To consider how viable MIDP is as a general-purpose programming framework, it's useful to explore which packages and classes are excluded from it when compared with the standard edition. Of course, MIDP provides its own classes for graphics and sound, so there are no AWT, Swing, or sound-related packages from the standard edition. Similarly, MIDP has its own (limited) security classes, so there are no javax.security packages either. Since the Generic Connection Framework covers connectivity, packages relating to CORBA and network connections are also excluded. RMI likewise is not part of MIDP; although there is a separate J2ME RMI profile, it can only be used with the CDC configuration, not with CLDC. Other missing packages are those that relate to JavaBeans, reflection, XML, printing, and JNDI.

Although MIDP excludes many packages that are present in the standard edition, many of these have equivalents in the MIDP packages or, like printing, are not particularly important for mobile devices. However, it is in those packages that are included in MIDP that we find the most constraining factors, since these packages have far fewer classes in MIDP than in the standard edition. For example, MIDP includes only one interface and nine classes from java.util, as opposed to 14 interfaces and 41 classes in the standard edition (version 1.4), principally due to the absence of the Java 2 Collections Framework.

• Open Source, Open Sesame?

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5