At the heart of Java 2 Micro Edition (J2ME) are three core
concepts: configurations, profiles, and optional packages.
You can't write a J2ME application without understanding these
concepts, because they determine the features of Java that
you can use, which application programming interfaces (APIs)
are available, and how your applications are packaged.
Configurations
A configuration is a complete Java runtime environment,
consisting of three things:
- A Java virtual machine (VM) to execute Java bytecode.
- Native code to interface to the underlying system.
- A set of core Java runtime classes.
To use a configuration, a device must meet certain minimum
requirements as defined in the configuration's formal specification.
Although a configuration does provide a complete Java environment,
the set of core classes is normally quite small and must be
enhanced with additional classes supplied by J2ME profiles or
by configuration implementor. In particular, configurations
do not define any user interface classes.
J2ME defines two configurations, the Connected Limited Device
Configuration (CLDC) and the Connected Device Configuration
(CDC). The CLDC is for very constrained (limited) devices -- devices
with small amounts of memory and/or slow processors. The VM used
by the CLDC omits important features like finalization, while the
set of core runtime classes is a tiny fraction of the J2SE core
classes, just the basics from the java.lang, java.io
and java.util packages, with a few additional classes
from the new javax.microedition.io package. The CDC,
on the other hand, includes a full Java VM
and a much larger set of core classes, so it requires more memory
than the CLDC and a faster processor. The CDC is in fact a superset
of the CLDC. We'll discuss the configurations in detail in the
next two articles in this series.
Profiles
A profile adds domain-specific classes to a configuration
to fill in missing functionality and to support specific uses
of a device. For example, most profiles define user interface
classes for building interactive applications.
To use a profile, the device must meet all the
minimum requirements of the underlying configuration as well
as any additional requirements mandated by the profile's
formal specification.
There are several profiles in various stages of development.
The first profile to be released was the Mobile Information
Device Profile (MIDP), a CLDC-based profile for running
applications on cellphones and interactive pagers with small
screens, wireless HTTP connectivity, and limited memory.
Another CLDC-based profile under development is the
Personal Digital Assistant Profile (PDAP), which
extends MIDP with additional classes and features for
more powerful handheld devices. In terms of CDC-based
profiles, the Foundation Profile (FP) extends the
CDC with additional J2SE classes, the Personal Basis Profile
(PBP) extends the FP with lightweight (AWT-derived) user
interface classes and a new application model, and the
Personal Profile
extends the PBP with applet support and heavyweight UI classes.
We'll also be discussing these profiles later on in this
series.
Optional Packages
An optional package is a set of APIs in support
of additional, common behaviors that don't really belong
in one specific configuration or profile. Bluetooth support, for
example, is defined as an optional package. Making it part of
a profile wouldn't work, because none of the behaviors
of a profile can be optional -- if a device supports a profile,
it must support the entire profile -- and that would limit
the profile to Bluetooth-enabled devices.
Optional packages have their own minimum requirements,
of course, just like configurations and profiles. Optional
packages also have specific dependencies on a particular
configuration and/or one or more profiles -- they do not
define a complete runtime environment, just sets of
related APIs.
There are many optional packages in development, including
the RMI Optional Package, which adds RMI
support to CDC/FP-based profiles, the Java APIs for Bluetooth,
which adds Bluetooth support to CLDC-based profiles, and
the JDBC Optional Package for CDC/Foundation Profile,
which defines a subset of JDBC (database access APIs) for use
with CDC/FP-based profiles. Again, we'll be covering these
later on in the series as the need arises.
The KVM and CVM
Two other terms you'll see mentioned in J2ME literature
are KVM and CVM. These are the names of
Java virtual machines for the CLDC (KVM) and the CDC (CVM),
written specifically to work in the constrained environment
of a handheld or embedded device and to be easily ported
to different platforms. It should be noted, however, that
the CLDC and CDC specifications do not require the use of
the KVM or the CVM, only the use of a VM that adheres
to the requirements of the specification in question. While
many device manufacturers license the KVM or CVM from
Sun Microsystems to serve as the core of their J2ME
implementation, they are not required for J2ME compliance.
It is a mistake, therefore, to consider the CLDC and KVM
as synonymous, and similarly for the CDC and the CVM.
What It All Means
It should now be apparent that "J2ME application"
is an ambiguous term. For what profile
is the application intended? Which optional packages does it
require? How much memory does it take? These are the questions
you must ask yourself before you start application development,
because they determine which language features and which
classes your application can use. If you limit your application
to CDC-based profiles, for example, you make development simpler
of the many familiar J2SE APIs, but
you cut out the low-end devices from your potential
install base. Targeting CLDC-based profiles, on the other hand,
makes your development task harder, especially when trying
to shrink the size of your application to run on as
many of the smaller devices as possible. These are the
kinds of tradeoffs you'll have to make as you begin
to work with J2ME. The information in this series will
help you decide what's really important.
Next: The Connected Limited Device Configuration
Eric Giguère is the author of Java 2 Micro Edition, the first
book about J2ME, and co-author of Mobile Information Device Profile for
Java 2 Micro Edition, both published by John Wiley & Sons. He works as a
software developer for iAnywhere Solutions, a subsidiary of Sybase. For more
information about Eric, see his web site or drop him a note at ericgiguere@ericgiguere.com.
# # #
IE 7
Firefox 2.0
