The Next Generation of Java 2 Micro Edition
By Mark Balbes, Ph.D., OCI Principal Software Engineer
The Java 2 Micro Edition (J2ME) 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 Enabling the Wireless Enterprise with Java 2 Micro Edition we explored how the J2ME MID Profile can be used to extend an enterprise into the wireless space. In this article, we will review three new specifications:
- The Connected Limited Device Configuration Version 1.1
- The Mobile Information Device Profile 2.0
- The PDA Profile for the J2ME Platform 1.0
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 March 2002, CLDC Version 1.1 was released for public review. CLDC 1.1 was 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
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
Absent from the changes is support for reflection, leaving CLDC-based profiles still without support for this very powerful technology.
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). Nevertheless, 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-Permissionsis used to request required permissions. If the requested protected capabilities are not available on the device, the suite should not be loaded.
MIDlet-Permissions-Optis used to request permissions that are optional for the proper operation of the suite. If the protected operations are unavailable, a
SecurityExceptionwill be thrown.
Currently, only the
javax.microedition.io.HttpsConnection classes are protected.
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 a JAR file, the device must treat it as a request to install the MIDlet suite. If the URL is of the form "tel:", 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 if he or she wants to proceed. This is especially important because 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.
The javax.microedition.io package includes new
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
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);
The most important addition to the lcdui user interface package is the inclusion of a
In MIDP, a user interface can be created using the high-level API, which includes predefined items thatcan 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
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 both a
Canvas and a
Form on the screen at the same time. Therefore, any customization forces the developer to create a completely customized screen using
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 that 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.
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, which can create large backgrounds by tiling smaller images.
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.
Playeris responsible for playing the sounds. Each
Controls, the nature of which are content dependent. For example, the API specifies a
Manageris responsible for creating an appropriate
Playerbased 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
Managercan also play generated tones through a simple API.
- A special player uses a
ToneControlto 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.
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.
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.
PIM class is the primary entry point into the API. It contains only static methods, some of which are used to list the available
ToDoLists) and others of which are used to open the desired List. Lists can be opened in
READ_ONLY mode or in
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.