Several years ago Motorola, Inc., and Sun Microsystems, Inc., recognized a potential new market for the Java programming language. Small mobile devices, such as cell phones, were becoming more powerful but did not provide a common programming platform. With different processors, operating systems, and capabilities, it was impossible to write an application that would work on more than one family of devices.

This situation is ideal for Java - its interpretive nature hides hardware differences and provides a single, consistent set of APIs for developers to write to. The only problem was that Java was big, too big for the typical cell phone, whose memory is measured in kilobytes rather than the megabytes that the Java Virtual Machine and associated APIs needed.

To meet this new market, the two companies started a development program to trim the JVM until it could fit into limited, battery-powered mobile devices. Once they proved that it could be done and demonstrated it at JavaOne in 1999, they decided to standardize it through the Java Community Process. This effort produced the Connected, Limited Device Configuration, CLDC 1.0, and the Mobile Information Device Profile, MIDP 1.0, both of which are part of the Java 2 Micro Edition (J2ME).

MIDP 1.0
MIDP 1.0's goals were simple: define a small Java profile that would run on a variety of small devices. At a minimum, the devices would have a screen size of 96x54 pixels, with one-bit display depth and approximately square pixels. They could use a keyboard (either QWERTY or phone-style) or touch screen for user input and have two-way, possibly intermittent, wireless networking. Memory was quite limited, but would include nonvolatile storage for user applications and their data. The Java classes defined by the MIDP 1.0 specification were sufficient to develop small applications, but were quite limited in their display and interaction capabilities.

Many developers recognized these limitations almost immediately on release of the final specification and started asking for changes. Among other limitations, the MIDP 1.0 user interface classes (called, together, the LCDUI) defined only a small selection of user interface components, and this selection wasn't extensible. There was no way to position the elements, so there was no way to group elements on screen. The specification required MIDP-compliant devices to support HTTP networking, but e-commerce applications need HTTPS for security. There was also no security differentiation for MIDP applications (MIDlets). Although the Java sandbox security model provided security from rogue MIDlets, MIDP 1.0 did not provide a way for a device manufacturer or service provider to define trusted MIDlets that could be given greater access to a device's capabilities. Finally, the sound capabilities defined by the first MIDP specification were limited.

All these limitations were required by the restricted capabilities of cell phones, PDAs, pagers, and other small portable devices in development during the original MIDP committee meetings. Since the hardware has been improving rapidly, a follow-up committee was quickly established to expand the MIDP capabilities to match new hardware and to address the concerns and problems identified in the first specification. The new capabilities defined in the next-generation MIDP specification (MIDP 2.0) include new graphics and user interface classes, secure communications, a MIDlet security model, better sound capabilities, and enhanced communications methods.

The MIDP 2.0 committee recognized from the beginning that the new MIDP specification must remain compatible with MIDP 1.0. The first MIDP specification was limited, but it was also popular. By the time the MIDP 2.0 specification would be ready, there would be hundreds of thousands, perhaps millions, of MIDP 1.0 devices on the market. It wouldn't be practical to declare them obsolete and start over. The committee decided that MIDP 2.0 would supplement, not supplant, MIDP 1.0. Device manufacturers and developers could continue to develop for MIDP 1.0 if they didn't need the newer features, or could design to MIDP 2.0 requirements for higher-end devices and applications.

Let's look at the new features.

Security
Probably the most necessary of the higher-end services is secure HTTP connections. Many of the applications proposed for MIDP-class devices are e-commerce applications - simple things like the ability to buy movie tickets online while traveling to the theater. Other applications that transmit personal data or produce billing information also require secure communications. Although these applications are possible without secure HTTP, most people don't want to risk their credit card or personal information over insecure network links. In real life, HTTPS is a requirement for any application that expects to send secure information to a Web site.

MIDP 2.0 satisfies this need with several new components. The HttpsConnection interface defines the necessary methods and constants to establish a secure HTTP connection in accordance with RFC 2818. The connection can be established in several ways. It can use HTTP over TLS, SSL 3.0, WTLS, or WAP TLS Profile and Tunneling. Information is authenticated through the use of X.509 certificates. At a lower level in the network stack, a SecureConnection interface provides the secure socket connection for those applications that want an SSL connection without using HTTPS. In addition, a SecurityInfo interface allows the application to access information about a secure connection. This information includes details of the protocol used, the cipher suite, and the certificate that authenticates the connection.

The ability to perform X.509 authentication also allows the VM to perform authentication on MIDlets. MIDP 2.0 defines a model for identifying trusted MIDlets and establishing the MIDlet's access to particular APIs or functions that require explicit authorization. This model begins with a protection domain that defines a set of permissions and related interaction modes. The permissions are divided into two sets: allowed and user. Allowed permissions don't require user interaction and provide access to protected functions within the protection domain. User permissions require that the user give explicit permission before the MIDlet can access protected functions or APIs.

A MIDlet can divide its permissions into critical and optional. Critical permissions are necessary for the MIDlet to operate at all. Optional permissions are noncritical and the MIDlet can operate without them, although with reduced capabilities. User permissions can also be divided into subsets. Blanket permissions are valid for every invocation of an API by a MIDlet suite, until the suite is removed or the user changes the permission. Session permissions are valid only until the MIDlet suite terminates and must be renewed for each invocation of the suite. One-shot permissions must be confirmed by the user for every invocation of the protected API.

The new security model in MIDP 2.0 provides not only for network security, but also for protection of the device. With secure HTTP and network connections, transmitted data is encrypted to protect it from prying eyes and network scanners. Inside the device, MIDlet authorization allows sensitive data and secure capabilities to be protected from unauthorized use. Together these new capabilities provide much-enhanced protection for both the mobile device and the user's data.

User Interface
The MIDP 1.0 user interface is quite limited, in keeping with the limited capabilities of the hardware it was expected to run on as well as the wide range of devices the MIDlets must run on. MIDP 2.0 recognizes that mobile device hardware is becoming more powerful with larger screens, faster processors, and more memory. The MIDP user interface components (LCDUI) have been extended and enhanced to take advantage of this increased power.

One limitation in MIDP 1.0 is that it's not possible to specify the display positions for Items. The reason for this is that because display sizes change so much in mobile devices, the MIDP 1.0 Expert Group decided the mobile device was the best authority for deciding how to lay out content. As a result, it's left to the implementation to place things on screen as best it can, which doesn't always result in a pleasing screen display.

To solve this problem, the Form and Item classes in MIDP 2.0 have been enhanced with a set of layout directives. Items can now be assigned horizontal and vertical layout values, affecting where their containing Form will display them. Developers can also now specify that a line break should appear before or after an Item, as well as whether an Item should be shrunk or expanded to help it fit in a particular position. In addition, the appearance of a StringItem or ImageItem can be specified: they can take an appearance value of Plain, Hyperlink, or Button. Two other changes have been made to Items: they can have commands added to them and programmers can now specify minimum and preferred sizes to display the Item. The minimum size is the smallest size at which the Item can function, and the preferred size is the smallest size that allows the entire Item to be displayed (with no clipping and a minimum of wrapping).

Another limitation of the 1.0 user interface classes is that they're not extensible. Developers are limited to the items defined by the specification and can't easily create new types of user interface widgets. MIDP 2.0 solves this problem by introducing a new class, CustomItem, as an extension of the LCDUI's Item class. A CustomItem can be subclassed to create new visual and interactive elements for Forms. These subclasses are responsible for responding to user interaction events such as pointer actions or key presses. They must also define the visual appearance of their content, including sizing, rendering, colors, fonts, and graphics. (The visual appearance of the CustomItem's label and border are handled by the implementation.) Finally, they're responsible for calling Item.notifyStateChanged() to notify listeners when their state changes.

Like other Items, CustomItems have the concept of minimum and preferred sizes that define the area needed by the entire Item. They add the concept of content size - the size of the content contained by the CustomItem (not including borders and label). The CustomItem subclass is responsible for handling events and displaying data in the area defined by the content size. The CustomItem subclass can support one or more of the user interaction modes defined by the Form on which it is displayed, but it's not required to support all possible interactions.

Finally, MIDP 2.0 introduces a new subclass of Item called a Spacer. This is a simple display element that's noninteractive. It allows a programmer to define its minimum height and width, making it useful for adjusting spacing between visual elements in a Form or for defining a minimum height for a row. A Spacer's label must always be null, and an application cannot add Commands to a Spacer.

Games
Games have been one of the driving applications on MIDP devices so far, but MIDP 1.0 provides little support specifically for game developers. Everything has to be done with the bare-bones MIDP 1.0 graphics functions, making game development much more difficult than it needs to be. The Expert Group that defined the MIDP 2.0 specification listened to the desires of the game developers and added classes to the specification to simplify game development and speed up game performance on most devices.

The gaming classes begin with a new subclass of Canvas called GameCanvas. In addition to the standard Canvas functions, GameCanvas allows synchronous graphics flushing and provides methods for checking the state of the game keys. This provides the basis for a game user interface.

A new abstract class called Layer allows the creation of game visual elements to be displayed on the GameCanvas. The Layer class has two defined subclasses: Sprite and TiledLayer. The TiledLayer class lets the developer create background and relatively fixed display objects. The Sprite class can be used to create animated foreground objects. Since a game may have several Layer subclasses (e.g., multiple Sprites moving in front of a TiledLayer background), a LayerManager class simplifies and automates the rendering process to display the Layers, making it easier for developers to define and maintain the foreground-to-background display order.

A Sprite is a Layer subclass that can be rendered from one of several identically sized frames stored in an Image. These frames can be displayed in sequence to animate the image. The Sprite's location can be changed, and it can be made visible or invisible. It can also be flipped and rotated about the horizontal and vertical axes. Sprites can detect collisions with Images, TiledLayers, and other Sprites.

A TiledLayer is a subclass of Layer that defines a grid of cells that can be filled with a set of tile images. This allows a developer to create a game background by combining elements from the tile images, rather than by using a large Image object. The tiled images are provided in a single Image object, and the tile size is specified along with the Image. A developer can also define animated tiles, which are groups of tiles associated with a single tile image. Just changing the image in the single tile can change all the tiles in the associated group.

The LayerManager class is used to simplify the display of the various Layer subclasses that make up a game. It maintains an ordered list of Layers that defines the display order, and provides a view window that lets the developer control the size of the visible region and its position relative to the LayerManager's coordinate system. In addition to controlling the view window's position in this system, the developer can also provide an offset for its position on the physical screen to make room for game controls or status displays.

Sound
Besides the display components, a major component for many applications is sound. People like to hear as well as see things happen. In some games, music is used to heighten tension or set a mood. Sounds and music can also be used by other applications, such as music players, or for distinguishing various types of event notifications. Unfortunately, the first MIDP release could not generate sounds except for predefined alerts. The JSR118 Expert Group addressed that problem in MIDP 2.0 and expanded the range of sound possibilities.

One complicating factor for this was the JSR135 Mobile Media API, which includes sound APIs in its scope. The JSR118 team was careful to define a set of sound APIs and functions that would be compatible with JSR135 in order to maintain upward compatibility with the more complex Mobile Media API. In keeping with this goal, the Expert Group defined an API set that allowed tone generation and audio playback while remaining protocol and content-format agnostic and using a minimal amount of resources.

The resulting specification defines three main parts:

1. A Manager controls the audio resources available on the device.
2. Applications use the Manager to request Players, and to query for the audio device's capabilities.
3. A Player is responsible for actually playing the audio content, and a Control interface exposes the different controls that a Player might have.

These APIs can be used in two ways: an application can use the Manager and/or Player classes to generate and play a single tone or a tone sequence, or the Player class can be used to play back sampled or synthesized sound formats.

The specification also defines two interfaces to control volume and tone generation. The ToneControl interface enables playback of a user-defined monotonic tone sequence, and the VolumeControl interface allows an application to manipulate the audio volume of a Player.

Application Downloading
Shortly after the first MIDP specification was released, a supplementary document came out describing recommended practices for Over-the-Air (OTA) provisioning of MIDlets to mobile devices. Although OTA downloading is optional for MIDP 1.0 devices, it's mandatory for MIDP 2.0. The Expert Group adopted the OTA provisioning method defined in the recommended practices document with minor changes. The MIDP 2.0 specification requires that devices be capable of discovering and downloading applications using the HTTP 1.1 protocol. Devices that communicate using the WAP June 2000 protocol must use an intermediate gateway to communicate with the HTTP provisioning server. Although HTTP provisioning is required, devices may also use other methods for downloading MIDlets, including iRDA, serial, or Bluetooth technologies.

Pushy, Pushy, Pushy
One of the great advantages of mobile devices is their ability to monitor some process (even if it's just the passage of time) and notify the user that an event has happened. The ability to receive unexpected communications and act on them is especially useful. Early J2ME devices could not do this because the first MIDP specification had no provision for receiving unexpected communication events. Their communications model was essentially that of a Web browser, reacting to user input and initiating communications only when the user wanted to.

The PushRegistry class in MIDP 2.0 changes all that. This new class maintains a list of inbound connections. A MIDlet can register a set of connections in two ways. When it is first loaded, its descriptor file must notify the Application Management Software (AMS) that it requires certain connections in order to run. If the connections are available, the AMS will register them. If the connections are not available, the AMS must abort the loading and notify the user that conflicts exist that prevent the MIDlet from being installed. Once a MIDlet is installed, it can register additional push connections using the dynamic registration methods in the PushRegistry. Once registered, the MIDlet has exclusive use of a connection.

Responsibility for registered connections is shared between the AMS and the MIDlet. A MIDlet that's running is required to handle all the communications on its registered connections. When the application is destroyed, the AMS assumes the responsibility of listening for inbound connections and starting the registered MIDlet when data is received. Whatever data was received is then passed on to the MIDlet, which assumes responsibility for the connection.

Communication Options
The first version of the MIDP specification required only that HTTP connections be supported, and so defined only an HttpConnection class. Experience has shown that additional connectivity is very desirable, so MIDP 2.0 defines several optional (but highly recommended) connection interfaces. These include the UDPDatagramConnection, SocketConnection, ServerSocketConnection, and SecureConnection. None of these are required in a compliant MIDP 2.0 implementation, but they should be implemented if possible.

The UDPDatagramConnection provides applications the opportunity to use UDP Datagrams for sending and receiving messages whose delivery is not guaranteed by the underlying network stack. The SocketConnection provides stream connections to specified hosts and ports without specifying a particular protocol. ServerSocketConnections allow an application to open a stream waiting for inbound connections, and the SecureConnection interface extends the SocketConnection to provide SSL connections for data streams.

In addition to these network connections, MIDP 2.0 defines a serial communication interface, the CommConnection, which defines a logical serial port connection. The logical serial port used by this connection is defined by the underlying host platform and may not correspond to a physical RS-232 serial port.

Conclusion
The MIDP 1.0 specification was a good first attempt at defining a subset of Java that could run on very restrictive, limited-hardware devices. Experience rapidly showed that additional features were needed to improve the capabilities of Java MIDlets intended for these devices. MIDP 2.0 addresses those needs and recognizes the greater functionality of newer cell phones and other small mobile devices. Increased networking capabilities, enhanced user interface classes, and a host of other improvements provide a more robust, full-featured programming environment that enables application developers to create better applications more easily. At the same time, more powerful security features protect the user's data from inappropriate use and permit sensitive data to be exchanged safely with remote servers. With MIDP 2.0, small mobile devices can become fully functional mobile data systems, enabling their users to stay connected wherever they go.

For more information on the specification, the companies, and the people involved in developing it, please visit http://jcp.org/jsr/detail/118.jsp.