A configuration is a specification that defines the software
environment for a range of devices defined by a set of characteristics that the specification
relies on, usually such things as:
• The types and amount of memory available
• The processor type and speed
• The type of network connection available to the device
A configuration is supposed to represent the minimum platform
for its target device and is not permitted to define optional features. Vendors are required to
implement the specification fully so that developers can rely on a consistent programming
environment and, therefore, create applications that are as device-independent as possible.
J2ME currently defines two configurations:
Connected Limited Device Configuration (CLDC)
CLDC is aimed at the low end of the consumer electronics range.
A typical CLDC platform is a cell phone or PDA with around 512 KB of available
memory. For this reason, CLDC is closely associated with wireless Java, which is
concerned with allowing cell phone users to purchase and download small Java
applications known as
MIDlets to their handsets. A large and growing number of
cell phone vendors have signed agreements with Sun Microsystems that will allow them to
begin using this technology, so the number of handsets with the capability to be
programmed in Java
will probably grow rapidly in the next few years.
Connected Device Configuration (CDC)
CDC addresses the needs of devices that lie between those
addressed by CLDC and the full desktop systems running J2SE. These devices have more
memory (typically 2 MB or more) and more capable processors, and they can,
therefore, support a much more complete Java software environment. CDC might be found on
high-end PDAs and in smart phones, web telephones, residential gateways, and
set-top boxes. Each configuration consists of a Java virtual machine and a core
collection of Java classes that provide the programming environment for application software.
Processor and memory limitations, particularly in low-end devices, can make it
impossible for a J2ME virtual machine to support all of the Java language features or
instruction byte codes and software optimizations provided by a J2SE VM. Therefore, J2ME VMs are
usually defined in terms of those parts of the Java Virtual Machine Specification and the
Java Language Specification that they are not obliged to implement. As an example of
this, devices targeted by CLDC often do not have floating point hardware, and a CLDC VM is
therefore not required to support the Java language types float and double or any of the
classes and methods that require these types or involve floating-point operations.
It is important to note that configuration specifications do not
require implementations to use any specific virtual machine. Vendors are free to create their
own VM or license a third-party VM, provided that it meets the minimum requirements of the
specification. Sun provides reference implementations of both configurations, each of which
includes a conforming virtual machine:
- The CLDC reference implementation is a source code and
binary product for the Windows, Solaris and Linux platforms. It includes the Kilobyte
Virtual Machine (KVM), a reduced-functionality VM that has a very small memory
footprint and incorporates a garbage collector that is optimized for a
memory-constrained environment. KVM, which is discussed in Chapter 2, is likely to
be used as the basis for most CLDC implementations in the near future, but there are
other VMs that could be used instead, such as the J9 VM from IBM.
- The CDC reference implementation is a source code-only
product for Linux and the Wind River VxWorks real-time operating system. The VM
included with this product, called CVM (see Chapter 7), implements the full range
of J2SE VM features as required by the CDC specification. However, it does not
include the HotSpot technology found in the J2SE Version 1.3 VM or even a
just-in-time compiler (JIT) as found in earlier J2SE releases. Several third-party vendors,
including Insignia Solutions and IBM, have plans to release their own CDC
implementations that include different virtual machines.
A configuration also includes a core set of Java language
classes. The core class libraries defined for a configuration (and for profiles) are required to
be based on those of the Java 2 platform. This promotes as much compatability as possible
between applications written for different J2ME platforms and those written with J2SE, and it
also reduces the learning curve for J2ME developers. Broadly speaking, this means that
developers can rely on the following:
- Where possible, J2ME must reuse J2SE classes and packages.
This means that, for example, it would not be acceptable for a J2ME configuration or
profile to eschew the java.util.Date class and introduce one of its own.1 As a result,
everything that you know about J2SE can be carried forward to J2ME, provided you
know the exceptions that apply to the configuration and profiles you are working
with. That information is available in the reference section of this book.
- When a J2SE class is incorporated into J2ME, new methods and
fields may not be added to it. Similarly, new classes cannot be added to a coopted
J2SE package. These rules ensure that code written for J2ME that uses only those
classes it shares with J2SE will compile and work on J2SE, thus making it possible to
share code between these platforms.