Introduction - Beginning J2ME: From Novice to Professional - page 6

Try to imagine a device that might be a MIDP device: mobile telephones and advanced
pagers are right in the groove, but entry-level PDAs could also fit this description.
More information about MIDP, including a link to the official specification document, is
at http://java.sun.com/products/midp/ . There are two versions of MIDP: MIDP 1.0 (JSR 37),
and MIDP 2.0 (JSR 118). Many of the currently available devices do and all new devices will
support MIDP 2.0. Compared to MIDP 1.0, MIDP 2.0 features a number of enhancements,
including support for multimedia, a new game user interface API, support for HTTPS connection,
and other features. Most importantly, MIDP 2.0 is fully backward compatible with MIDP 1.0.
JTWI standard compliance requires devices to implement MIDP 2.0 (see the next section
on platform standardization). This topic's focus will be on MIDP 2.0. We will mention MIDP 1.0
differences only in this introductory chapter as background information.
Platform Standardization
Given the profusion of configurations, profiles, and especially optional APIs, how do you know
what APIs are likely to be available on typical devices? Sun's answer to this question is JSR 185
( http://jcp.org/jsr/detail/185.jsp ), impressively titled Java Technology for the Wireless
Industry (JTWI) . This specification attempts to standardize software stacks to bring coherence
to the J2ME world. A reference implementation and a TCK (kit for compatibility testing) of the
unified software stack is made available with JSR 185. As currently specified, a JTWI-compliant
device must have MIDP 2.0 with CLDC 1.0 (or CLDC 1.1), and must support WMA (Wireless
Messaging API 1.0—JSR 120). If a JTWI device exposes video or audio API to applications, they
must also support Mobile Media API (MMAPI).
In the next generation of J2ME, a concept called Building Blocks is supposed to replace
configurations and profiles. A Building Block is just some subset of a J2SE API. For example,
one Building Block might be created from a subset of the J2SE java.io package. Conceptually,
a Building Block represents a smaller chunk of information than a configuration. Profiles, then,
will be built on top of a set of Building Blocks rather than a configuration.
The definition of Building Blocks is a JSR, which is briefly described here: http://jcp.org/
jsr/detail/68.jsp . Progress on JSR 68 has been extremely slow since its creation in June 2000.
In the meantime, JSR 185 will better serve as a standardization platform. Recently, lever-
aging the success of the JTWI work, Nokia and Vodafone have submitted a new JSR, JSR-248:
Mobile Service Architecture for CDC ( http://jcp.org/jsr/detail/248.jsp ), to define a new
standard software stack for the next generation of mobile devices.
Anatomy of MIDP Applications
The APIs available to a MIDP application come from packages in both CLDC and MIDP, as
shown in Figure 1-2. Packages marked with a + are new in CLDC 1.1 and MIDP 2.0.
CLDC defines a core of APIs, mostly taken from the J2SE world. These include fundamental
language classes in java.lang , stream classes from java.io , and simple collections from java.util .
CLDC also specifies a generalized network API in javax.microedition.io .