J2ME Core Concepts

J2ME Core Concepts:

Configurations, Profile and Optional packages are 3 major concepts.

Configurations:

A configuration is a complete Java runtime environment, consisting of three things:

1. A Java virtual machine (VM) to execute Java byte code.
2. Native code to interface to the underlying system.
3. 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.

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 CLDC Specification:

The CLDC is defined by a specification that has passed through the Java Community Process (JCP)

The CLDC specification defines three things:

1. The capabilities of the Java virtual machine (VM), which is not a full-featured Java VM.
2. A very small subset of the J2SE 1.3 classes.
3. A new set of APIs (application programming interfaces) for input/output called the Generic Connection Framework.

It’s also important to understand what the CLDC does not define. The CLDC does not define any APIs related to user interfaces. The CLDC does not define how applications are loaded onto a device or how they are activated or deactivated. These and other things are defined by the J2ME profiles that use the CLDC as their base. So while it’s true that the CLDC does define a complete Java runtime environment, the additional APIs defined by a profile or supplied by the vendor are really necessary to build useful applications.

The Virtual Machine:

The Java VM used in the CLDC is restricted in certain important ways when compared to a full-featured J2SE VM. These restrictions allow the VM to fit the memory and power constraints of the small devices that the CLDC target: the CLDC VM and classes can fit in 128K of memory. The primary restrictions on the VM are:

1. No floating point types.
2. No object finalization or weak references.
3. No JNI or reflection (hence no object serialization).
4. No thread groups or daemon threads (note that threads are supported, just not thread groups).
5. No application-defined class loaders.

Note that CLDC 1.1 relaxes some of these restrictions, in particular reenabling support for floating point types and weak references.

In addition to the above restrictions, the CLDC also requires class verification to be done differently. Class files are processed by an off-device class verifier, a process called preverification. At runtime, the VM uses information inserted into the class files by the preverifier to perform the final verification steps. Files that have not been processed by the preverifier are not loaded since they cannot be verified.

The J2SE Subset:

The subset of J2SE 1.3 included in the CLDC consists of classes from these three packages:

1. java.lang
2. java.io
3. java.util

Only selected classes from each package are included: for example, the java.util.Vector and java.util.Hashtable classes are included, but none of the collection classes are. The largest package is the java.lang package, which defines the classes that are fundamental to any java application, classes like java.lang.Object or java.lang.Integer. The java.io subset only includes abstract and memory-based classes and interfaces like java.io.DataInput or java.io.ByteArrayInputStream. The java.util subset only includes a few utility classes.

Some of the classes are subsets of their J2SE equivalents. Configurations are allowed to remove unnecessary methods or fields, but they cannot add new public or protected methods or fields.