Helping You Pass the Sun Certified Mobile Application Developer Certification

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: Understanding the Connected Limited Device Configuration (CLDC)