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'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.
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
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 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
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.
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
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 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
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
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:
MIDP 2.0 also defines a PlayerListener interface for receiving
asynchronous events generated by Players.
- A Manager controls the audio resources available on the device.
- Applications use the Manager to request Players, and to query for the
audio device's capabilities.
- 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
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.
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
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.
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.
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.
Roger Ritter is a programmer and developer support specialist for Motorola,
Inc. He supports mobile device manufacturers who are porting Motorola's J2ME
implementation to their own products.