Helping You Pass the Sun Certified Mobile Application Developer Certification

At the core of Java 2 Micro Edition (J2ME) are the configurations, the specifications that define the minimal feature set of a complete Java runtime environment. J2ME currently defines two configurations. In this article we look at the first of these, the Connected Limited Device Configuration, or CLDC for short.

The CLDC Specification

Like all J2ME technology, the CLDC is defined by a specification that has passed through the Java Community Process (JCP). At this time, there are two versions of the CLDC. Version 1.0, released in May of 2000, is known as Java Specification Request (JSR) 30. Version 1.1, currently in public review, is JSR 139. Because version 1.0 is the one that is currently shipping in devices, we'll concentrate on it.

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:

• No floating point types.
• No object finalization or weak references.
• No JNI or reflection (hence no object serialization).
• No thread groups or daemon threads (note that threads are supported, just not thread groups).
• 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:

• java.lang
• java.io
• 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.

The Generic Connection Framework

J2SE includes many classes for performing input and output, classes that are found in the java.io and the java.net packages. Unfortunately, there are a large number of I/O classes and they tend to encapsulate I/O models that are not necessarily found on all devices. For example, some handheld devices do not have file systems. Socket support is not universal, either.

What the CLDC has done, then, is to define a new set of APIs for I/O called the Generic Connection Framework. The GFC, part of the new javax.microedition.io package, defines interfaces for the different kinds of I/O that are possible and a factory class for creating objects that implement those interfaces. The type of object to create is specified in the protocol part of the URL (universal resource locator) passed to the factory class.

For example, a socket connection can be made using code like this:

import java.io.*;
import javax.microedition.io.*;

StreamConnection conn = null;
InputStream is = null;
String url = "socket://somewhere.com:8909";

try {
    conn = (StreamConnection) Connector.open( url );
    is = conn.openInputStream();
    .... // etc. etc.
}
catch( ConnectionNotFoundException cnfe ){
    // handle it 
}
catch( IOException e ){
    // handle it
}
finally {
    if( is != null ) try { is.close(); } catch( Exception e ){}
    if( conn != null ) try { conn.close(); } catch( Exception e ){}
}

The code above assumes that the device knows how to map the "socket" protocol in the URL to an object that implements the GCF's StreamConnection interface, which defines methods for obtaining the input and output streams of a socket connection. It should be noted, however, that the CLDC does not actually define any I/O implementations. In other words, the CLDC defines the interfaces of the GCF, but the implementation classes -- the ones that do the actual I/O -- are left to the profiles and/or the device vendor to define. For example, the Mobile Information Device Profile (MIDP) -- a CLDC-based profile -- requires support for a subset of HTTP 1.1 and so it recognizes the "http" protocol in URLs and returns objects that implement the GCF's ContentConnection interface.

Using the CLDC

By itself, the CLDC is a limited programming platform. Because it does not define any user interface classes or implement any I/O models, about all you can do for output is write to the System.out stream, which may or may not be captured to a console or file. You really need the extra classes defined by a J2ME profile (like those of the MIDP) or device-specific classes (like those on the RIM BlackBerry devices or certain Japanese i-Mode phones) to do anything interactive.

If you're still interested in trying out the CLDC, Sun has a reference implementation hosted on Windows or Solaris available for download from its website. This reference implementation includes the preverify offline verification utility as well as a CLDC VM and the CLDC runtime classes. See Sun's main CLDC page for links to it and to the CLDC specification. You can also use toolkits or integrated development environments like Sun's J2ME Wireless Toolkit, Metrowerks' CodeWarrior Wireless Studio, or Borland's JBuilder MobileSet to explore CLDC programming.

Next: Understanding the Connected Device Configuration (CDC)