J2ME Core Concepts – Brief introduction
By Eric Giguère
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.
MIDlets and Applets
Applets and MIDlets are different, but they do have some
similarities. They can both be packaged in JAR files. Both are run
in a sandbox to guard them against malicious applications. They
have similar life-cycle models. However, applets never really
succeeded as a way to deploy applications. So why will MIDlets
succeed where applets failed? There are several reasons why they
might. Applets suffered because of their slow download speeds and
lack of caching, a problem only recently addressed with Sun's Java
Plug-in. Unlike applets, MIDlets are downloaded permanently to a
device, which means that the user has to suffer through only a
single slow download. Applets also ran into problems due to
different, buggy, browser-based Java implementations in addition
to the significant set of API changes that were made between the
original Java 1.02 (with its limited set of classes) and the
current J2SE 1.3 (Java 1.1 support was particularly slow to appear
in browsers). MIDlets won't suffer this same fate because MIDP
APIs are rich and MIDP implementations must pass Sun's rigorous
compatibility tests. Applets might have fared better if Java
Plug-in technology had been available from the start to correct
these deficiencies.
Futures and Alternatives
It will be interesting to see how J2ME develops—especially the
CLDC-based profiles. The upcoming PDA Profile should prove to be a
real boon for Java developers who have been itching to write Palm
and PocketPC applications in Java. Whether J2ME succeeds will
depend on how many manufacturers start supporting it in their
devices and how many interesting applications are developed.
You can also choose among several alternatives to J2ME. Qualcomm
recently announced a new C++-based, interpreted system called
Binary Runtime Environment for Wireless (BREW), which the company
hopes to license to cell phone vendors. BREW also supports Java
through HP's MicroChai virtual machine (VM). For handhelds, an
open-source alternative is Waba, a VM that runs a subset of Java
on Palm and Windows CE platforms. (See the article "Let's Get
Small".) There's also AppForge, which lets you develop Palm
programs with Visual Basic.
|
|
|
