The Next Generation of Java 2 Micro Edition

The Next Generation of Java 2 Micro Edition

by Mark Balbes, Ph.D., Principal Software Engineer

August 2002

Introduction

The Java 2 Micro Edition is designed to target devices that have fewer capabilities than standard desktop computers. To take advantage of the wide variety of capabilities in different devices, J2ME provides many different configuration and profile specifications.

Until now, the only available configuration has been the Connected Limited Device Configuration (CLDC) 1.0 and the only available profile has been the Mobile Information Device Profile (MIDP) 1.0. However, within the last couple of months, many new specifications have been released for public review. Although no implementations of these specifications exist, we now have a good idea of the capabilities that future J2ME devices may support.

In a previous SETT article, "Enabling the Wireless Enterprise with Java 2 Micro Edition", we explored how the J2ME MID Profile can be used to extend the enterprise into the wireless space. In this article, we will review three new specifications:

New capabilities in CLDC 1.1

The CLDC 1.0 specification has been available for over a year. Free and commercial implementations exist for many devices, including Palm devices, PocketPCs, and a variety of mobile phones. However, CLDC 1.0 has many limitations, most notably the lack of floating point support, that make it difficult to use to build certain types of applications. For example, a simple calculator application must handle floating point calculations such as division in software.

In March 2002 the Connected Limited Device Configuration Specification Version 1.1 was released for public review. CLDC 1.1 has been developed through the Java Community Process (JCP) as Java Specification Request 139 (JSR-139).

The most notable addition to CLDC 1.1 is the inclusion of floating point support. The Float and Double classes have been added to the java.lang package and APIs have been updated as appropriate. For example, the java.lang.Math class now includes methods that operate on floats and doubles.

CLDC 1.1 also adds some of the weak reference classes from J2SE. Specifically, the java.lang.ref package has been added which includes the abstract Reference class and the WeakReference class.

Absent from the changes is support for reflection, leaving CLDC-based profiles still without support for this very powerful technology.

MIDP 2.0

The Mobile Information Device Profile (MIDP) 1.0 is currently the only profile that is implemented and in use commercially. The public review copy of the MIDP 2.0 Specification has only recently been available (since April 2002). Never-the-less, this specification promises important new capabilities.

First, MIDP 2.0 has been designed to work with either CLDC 1.0 or 1.1. This means that MIDP applications can take advantage of the enhanced capabilities of CLDC 1.1 once implementations become available.

A new security model partitions core functionality into protected and unprotected classes. To access any protected functionality, the MIDlet suite must specify permissions using the MIDlet-Permissions and MIDlet-Permissions-Opt attributes. MIDlet-Permissions is used to request required permissions. If the requested protected capabilities are not available on the device, then the suite should not be loaded. MIDlet-Permissions-Opt is used to request permissions that are optional for the proper operation of the suite. If the protected operations are unavailable, a SecurityException will be thrown.

Currently, only the javax.microedition.io.HttpConnection and javax.microedition.io.HttpsConnection classes are protected.

API Enhancements

Enhanced Support for Accessing Device Capabilities

One of the common complaints about MIDP 1.0 was its limited ability to take advantage of native features on the device. In fact, from a MIDlet it was not even possible to initiate a phone call, a feature that is available to WAP applications.

In MIDP 2.0, the MIDlet class has been enhanced to include the method

boolean platformRequest(java.lang.String URL)

Calling this method initiates a request to the device to launch an appropriate application to handle the content of the URL. This should be done while the MIDlet is running. However, if the device doesn't have enough resources to run both applications simultaneously, it must launch the application as soon as the MIDlet has been stopped.

If the URL points to a MIDlet descriptor or JAR file, the device must treat it as a request to install the MIDlet suite. If the URL is of the form "tel:<number>" then the device must launch an application to initiate a phone call.

In either of the above cases, the request must be confirmed by the user before it is carried out. For example, if the MIDlet requests to initiate a phone call, the device should show a dialog to the user asking them if they want to proceed. This is especially important since any kind of network or calling activity may incur charges to the user.

Device makers are free to support additional URL schemes to expose the unique capabilities of their devices.

Networking

The javax.microedition.io package includes new PushRegistry and PushListener classes and a ServerSocketConnection interface to support inbound datagram and socket connections. MIDlets may statically register for notification of incoming connections by setting appropriate properties in the descriptor file. Using the PushRegistry, registration may also be configured dynamically in the MIDlet. Using these mechanisms, MIDlets may be started by the device's application manager, i.e. MIDlet.startApp() will be called, in response to an incoming connection.

To support an application that is interested in multiple, short-term inbound connections (for example, a turn-based game) a PushListener may be registered with the PushRegistry. The PushListener is informed of any new inbound connections.

To support secure connections, a SecureConnection interface has been defined. A secure connection using SSL can be easily created using the connector framework.

String url = "ssl://host.com:79";
SecureConnection conn = (SecureConnection)Connector.open(url);

User Interface

The most important addition to the lcdui user interface package is the inclusion of a CustomItem class. In MIDP, a user interface can be created using the high-level API which includes predefined items which can be placed on forms. Forms allow items to be laid out on a two-dimensional grid. To support custom screens, for example a complex game board, there is also a low-level Canvas class similar to the AWT Canvas.

In MIDP 1.0, there is no mechanism to create custom items for the high-level API. Even worse, it is not possible to have a Canvas and a Form both on the screen at the same time. Therefore, any customization forces the developer to create a completely customized screen using Canvas.

In MIDP 2.0, lcdui items may be mixed with custom items on the same form. The CustomItem class defines the notion of a content area. Subclasses can define both a minimum and preferred size. By overriding the paint() method, any image can be drawn into this area.

Depending on the capabilities of the device, the user may interact with the custom item in one of several ways. For devices which allow in-line editing, the item may respond to input events as appropriate. If the device or the custom item does not support in-line editing, the custom item should bring up a separate editor. It is recommended that the custom item support at least the external editor mode for maximum portability. If the item supports multiple interaction modes, it can query the device to determine which interaction modes are supported.

A Spacer class has also been added to the API. It can be used to put arbitrary space between items in a row of a form. In addition, it can be set to a fixed height to help control the height of a row.

The Game API

The javax.microedition.lcdui.game package has been added to explicitly support gaming. It includes a GameCanvas, which enhances the lcdui Canvas by adding features to simplify game development and improve performance. Features include an off-screen graphics buffer and the ability to query for the state of keys rather than waiting to be notified.

Lively foreground characters can be created using sprites. Sprites are created with the Sprite class. Sprites may be animated by defining a sequence of static images. Backgrounds may be defined using the TiledLayer class that can create large backgrounds by tiling smaller images.

Multimedia Support

MIDP 2.0 includes a Media API which is a subset of the J2ME Mobile Media API (JSR 135). Although the Mobile Media API is designed to support a wide variety of multimedia formats, the MIDP subset only supports sound.

The API introduces three key objects for controlling the playback of sound. The Player is responsible for playing the sounds. Each Player has multiple Controls, the nature of which are content dependent. For example, the API specifies a VolumeControl. A Manager is responsible for creating an appropriate Player based on the format of the content to be played. Content can be stored locally, e.g. as a resource in a jar file, or downloaded through a network connection. The Manager can also play generated tones through a simple API. A special player uses a ToneControl to define a sequence of tones and manipulate their pitch and duration.

Over-the-air User Initiated Provisioning

After the MIDP 1.0 Specification was released, the MIDP Expert Group released a document describing the desired behavior of over-the-air user-initiated provisioning. This document has been updated and added as a mandatory requirement of the MIDP 2.0 specification. Specific requirements for MIDP provisioning in a WAP 2000 environment are explicitly described.

The PDA Profile

J2ME developers have waited a long time for the PDA Profile 1.0 specification. The JSR was approved way back in August, 2000. Part of the delay was due to a disagreement about how the PDAP should relate to the MIDP. Sun took the position that PDAP should be a superset of MIDP. Palm wanted new APIs, concerned that MIDP was too limiting.

Based on the public review specification released in July 2002, it appears that both sides won. The PDA Profile is a superset of MIDP 1.0 (meaning that it includes all of the MIDP 1.0 APIs) while also adding powerful new capabilities.

As a superset of the MIDP profile, PDA applications (called PDAlets) follow the same lifecycle as MIDlets. The only distinction between them being the attributes declared in the descriptor and the APIs which are available. A MIDlet can run in a PDAP environment without modification.

Even more useful, PDAlets and MIDlets can be packaged in the same suite. If a PDAlet is given the same name as a MIDlet in the descriptor file, then only the PDAlet will be visible in a PDAP environment and only the MIDlet will be visible in a MIDP environment. In this way, developers can supply a single application suite with feature-rich applications for more capable devices and more constrained applications for less capable devices.

User Interfaces

Because it must support all of MIDP 1.0, the PDA Profile must support both the high and low level GUI APIs defined in the javax.microedition.lcdui MIDP package. In addition, PDAP adds support for a subset of the Personal Profile 1.0 AWT, which itself is a subset of the JDK 1.1.8 AWT.

Missing from the PDAP AWT is support for serialization, object cloning, buffered images and alpha composite image manipulation. Also, PDAP does not guarantee the AWT to be thread safe. Components must be manipulated on the event thread using the same techniques as J2SE Swing components.

Although the AWT supports multiple Frames, it is up to each device implementation to determine whether visible frames will be shown as overlapping frames as in J2SE or whether some other paradigm will be used. For instance, visible frames may be stacked like a deck of cards where only the top card is visible and consumes all of the screen real estate.

AWT and lcdui components can be used in the same application but only one type of component can be visible at a time. If an lcdui Screen gains input focus it will hide any AWT Frames. Likewise, if a Frame gains input focus, it will hide any lcdui screens.

Networking

PDAP builds on the MIDP Connector architecture by adding two new types of connections in addition to the MIDP-mandated HTTP support.

CommConnection defines a logical serial port. It can be used to communicate over an infrared (IR) port or through a docking cradle.

FileConnection is used to connect to a logical file system. Although this could mean a traditional file system on a disk, it can also be used to connect to removable memory cards. In addition, the FileConnectionRegistry class can be used to discover logical file systems and be notified when new ones become available.

Personal Information Management

The most common use for any PDA device is information management. The PDAP defines a PIM API for accessing Calendar information, Contact lists, and To Do lists. To support this capability on devices that don't have it locally, the PIM API will also access remote PIM databases. In addition, data import and export is supported by inclusion of the vCard 3.0 and vCalendar 1.0 formats.

The PIM class is the primary entry point into the API. It contains only static methods, some of which are used to list the available Lists (ContactList, EventList, and ToDoLists) and others of which are used to open the desired List. Lists can be opened in READ_ONLY mode or in READ_WRITE mode.

Summary

As you can see, we are on the verge of some very exciting times. With these new specifications, plus more on the way, J2ME will soon be as rich and varied as J2SE and J2EE.

In future articles, we will explore these new APIs in depth and review available implementations.

References

Software Engineering Tech Trends (SETT) is a regular publication featuring emerging trends in software engineering.