Connected, Limited Device Configuration (CLDC)

 
Connected, Limited Device Configuration (CLDC)
The second of the two J2ME configurations, the Connected, Limited Device Configuration
(CLDC), supports personal, mobile devices, which constitute a significantly less powerful class of
devices than the one that the CDC supports. The CLDC specification identifies devices in this
category as having the following characteristics:
• 160 to 512 KB total memory available for the Java platform
• 16-bit or 32-bit processor
• low power consumption, often battery powered
• intermittent network connectivity (often wireless) with potentially limited bandwidth
The goal of the CLDC is to define a standard Java platform for these devices. Because of the wide
variety of system software on various personal devices, the CLDC makes minimum assumptions
about the environment in which it exists. For example, one OS might support multiple concurrent
processes, another might or might not support a file system, and so forth.
The CLDC is different from, yet also a subset of the CDC. The two configurations are
independent of each other, however, so they should not be used together to define a platform.
Figure 1.2 shows the relationship between the two configurations and the J2SE platform.
Figure 1.2. The CLDC is a proper subset of the CDC. Neither the CLDC nor the CDC
is a proper subset of the J2SE platform, however, because both of these
configurations add new classes necessary to deliver services on their respective
families of devices.
8
Like the CDC, the CLDC specifies the level of support of the Java programming language
required, the required functional support of a compliant Java VM, and the set of class libraries
required.
Java Language Support. The CLDC specification omits support for the following features of the
Java language:
• floating point calculations
• object finalization
• the java.lang.Error class hierarchy in its entirety
Of course, these features involve the VM as well and are discussed in chapter 5 of the CLDC
specification ("Adherence to Java Virtual Machine Specification"). I address them here, however,
because they have a language-level presence that affects programmers.
The lack of floating point support is the main language-level difference between a Java virtual
machine that supports CLDC and a standard J2SE VM that is visible to programmers. This means
that programs intended to run on the CLDC cannot use floating point literals, types, or values.
You can't use the float built-in type, and the java.lang.Float class has been removed from
CLDC libraries. This feature is not present because of the lack of floating-point hardware or
software on most mobile devices.
Object finalization is also absent. This means that the Object.finalize() method has been
removed from the CLDC libraries.
The java.lang.Error exception hierarchy has also been removed from the CLDC libraries
and is therefore not available to applications. The primary reason that error handling is absent is
memory constraints on mobile devices. This typically doesn't create any disadvantages for
applications development; after all, applications are not supposed to recover from error conditions.
And the resource cost of implementing error handling is expensive, beyond the capabilities of
today's mobile devices. Moreover, error recovery is device-specific on embedded devices like
mobile phones. In consequence, it doesn't make sense to stipulate the recovery mechanism that
devices should use. This mechanism may well be outside the scope of an embedded VM.
9
Java Virtual Machine and Library Support. The CLDC specifies requirements for a Java
virtual machine. It defines a VM that is highly portable and designed for resource-constrained
small devices. Support for several features that exist in a standard J2SE VM have been omitted
from the CLDC specification. The following list describes the features that are not supported in a
CLDC-compliant VM. The features in this list have been omitted because of either changes to
libraries or security concerns:
• Java Native Interface (JNI)
• user-defined class loaders
• reflection
• thread groups and thread daemons
• finalization (no Object.finalize() method in CLDC libraries)
• weak references
• errors (a small subset of J2SE errors is supported)
• class file verification
Among these unsupported features, class file verification deserves further mention. The VM in the
CLDC specification still performs this process, but it uses a two-step process and a different
algorithm that requires fewer computation resources than the standard J2SE verifier. In addition,
there is a new preverification tool, which you will learn about in chapter 2.
The VM that comes with the CLDC reference implementation is called the Kilobyte Virtual
Machine (KVM), so named because it uses only a few KB of runtime memory. It is a reference
implementation that adheres to the CLDC specification's description of a compliant VM. The
KVM is not a full-featured J2SE VM.
The specification of the features that a VM supports includes a specification of the libraries that it
supports. The CLDC specification details the libraries that an implementation must support.
As you know, a configuration is the basis for one or more profiles. The CLDC is a configuration
on top of which one or more profiles are to be built in the same way that the Foundation Profile is
built on top of the CDC. The intention is that the APIs in the CLDC profile support application
development for the mass market of personal devices. The CLDC therefore targets third-party
application developers. This is somewhat different than the CDC, which targets OEM developers.
Table 1.4 lists the packages that comprise the CLDC. Notice that it is quite a bit smaller than the
list of packages contained in the CDC, shown earlier in Table 1.1.
The first three packages use the java. prefix in their name because each one contains a subset of
the standard J2SE platform classes. The last one, however, must use the javax. prefix because it
defines a new "standard extension" that is not part of the core Java platform.
Table 1.4. CLDC Packages
CLDC Package Name Description
java.io Standard Java IO classes and packages; subset of the J2SE
package
java.lang VM classes and interfaces; subset of the J2SE package
java.util Standard utility classes and interfaces; subset of the J2SE
package
javax.microedition.io CLDC generic connection framework classes and interfaces
Mobile Information Device Profile. Because the category served by the CLDC encompasses so
many different types of personal devices, potentially many different profiles are necessary to
support them all. The most popular and well known of these is the Mobile Information Device
10
Profile (MIDP), sometimes called the MID Profile. The MIDP layers atop the CLDC and defines a
set of user interface (UI) APIs designed for contemporary wireless devices.
Following in the tradition of Java parlance, MIDP applications are called MIDlets. A MIDlet is a
Java application that uses the MIDP profile and the CLDC configuration. This book concentrates
on teaching you how to write MIDlets, because the vast majority of J2ME programmers will
encounter the CLDC/MIDP platform far more often than other J2ME platforms. And, from a
practical standpoint, the MIDP is the only profile currently available.
Another profile, the PDA Profile, is currently in its definition stage. PDAs also
belong to the general category of mobile information devices. The PDA profile
might never be implemented, however, because it's questionable whether it
offers enough differences and enhancements to the MIDP specification to
warrant its development. The PDA Profile also poses portability challenges for
developers.
The MIDP specification, like the CDC's Foundation Profile, was produced by an expert group, in
this case, the Mobile Information Device Profile Expert Group, which is an international forum
that includes representatives from several companies in the mobile device arena. The MIDP
targets mobile information devices (MIDs), such as mobile phones, two-way pagers, and so forth,
which have roughly the following characteristics:
• screen size of approximately (at least) 96x54 pixels
• display depth of 1 bit
• one- or two-handed keyboard, touchscreen input device
• 128 KB nonvolatile memory for MIDP components
• 8 KB nonvolatile memory for application-persistent data
• 32 KB volatile runtime memory for Java heap
• two-way wireless connectivity
Because the range of MID capabilities is so broad, the MIDP established a goal to address the
least common denominator of device capabilities. The MIDP, therefore, specifies the following
APIs:
• application (MIDP application semantics and control)
• user interface
• persistent storage
• networking
• timers
Table 1.5 lists the packages that comprise the MIDP.
Table 1.5. MIDP Packages
MIDP Package Name Description
javax.microedition.lcdui UI classes and interfaces
javax.microedition.rms Record management system (RMS) supporting
persistent device storage
javax.microedition.midlet MIDP application definition support class types
javax.microedition.io MIDP generic connection framework classes and
interfaces
java.io Standard Java IO classes and interfaces
java.lang VM classes and interfaces
11
java.util Standard utility classes and interfaces
You'll learn more about the programming details of the APIs in Table 1.5 in chapters 3 through 9.
A MIDP implementation must consist of the packages and classes specified in the MIDP
specification. Additionally, it can have implementation-dependent classes for accessing native
system software and hardware.
Figure 1.3 juxtaposes the CDC and CLDC platform stacks. There is nothing inherent in either the
CDC or CLDC that prohibits a manufacturer from porting either platform to a given family of
devices. Nevertheless, the platform stacks—specifically, the configuration and profile features—
have been specified to address practical limitations of the different families of hardware devices.
Figure 1.3. The CDC targets fixed-connection, shared, stationary devices. The
CLDC targets personal, mobile, limited-connection devices.