Helping You Pass the Sun Certified Mobile Application Developer Certification

The second configuration at the core of Java 2 Micro Edition (J2ME) is the Connected Device Configuration, or CDC for short.The CDC is a superset of the Connected Limited Device Configuration (CLDC). It provides a much more conventional Java 2 runtime environment.

The CDC Specification

Like the CLDC (see my previous article, The Connected Limited Device Configuration (CLDC)), the CDC is defined by a specification that has passed through the Java Community Process (JCP). The CDC, known as Java Specification Request (JSR) 36, was released in March 2002.

The CDC specification is a much smaller document than the CLDC specification because the CDC is much closer to a Java 2 Standard Edition (J2SE) runtime environment than the CLDC. The CDC specification defines four things in particular:

1. The capabilities of the Java virtual machine (VM). Unlike the CLDC, the CDC VM is a full-featured VM.
2. A subset, much larger than the CLDC's, of the J2SE 1.3 classes.
3. The same APIs (application programming interfaces) that are new to the CLDC -- in other words, the Generic Connection Framework (GCF).
4. Support for file- and datagram-based input/output using both the GCF and the familiar java.io and java.net classes.

Note that, just like the CLDC, the CDC does not define any user interface classes or how applications are loaded and activated: these are left for the profiles to define.

The Virtual Machine

The CDC supports a complete, full-featured Java 2 virtual machine (VM) as defined in The Java Virtual Machine Specification. The low-level interfaces for calling native code, connecting to debuggers, and profiling code are optional, but if supported they must be the standard interfaces -- Java Native Interface (JNI), Java Virtual Machine Debugging Interface (JVMDI), and Java Virtual Machine Profiling Interface (JMVPI) -- used in Java 1.3.

Note that the CDC does not require preverification of classes, as full class verification is done on the device by the VM. Classes that have been preverified can also be used, of course, since the additional information added to the class files by the preverifier is ignored.

Because the VM is full-featured, and there are more classes, the minimum memory footprint for the CDC is larger than the CLDC's: the device needs at least 512K for the runtime environment, plus at least 256K to hold and run applications.

The J2SE Subset

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

• java.io
• java.lang
• java.lang.ref
• java.lang.math
• java.net
• java.security
• java.security.cert
• java.text
• java.util
• java.util.jar
• java.util.zip

As you can see, the CDC includes many more packages than the CLDC, and many more classes even in the shared packages. For example, the CDC includes the collections classes from the java.util package, while the CLDC does not. This makes the CDC a much more J2SE-like environment than the CLDC. There are still classes missing, of course. For example, the java.net package as defined by the CDC only includes the classes related to datagram sockets, not stream sockets.

The Generic Connection Framework

Since the CDC is a superset of the CLDC, it includes the Generic Connection Framework (GCF). Unlike the CLDC, however, the CDC also requires GCF support for two specific connection types: files and datagrams. This makes sense because the CDC includes the file classes from the java.io package and the datagram classes from the java.net package. It is therefore straightforward for the device manufacturer to write GCF implementation classes that simply map GCF requests (using the file or datagram protocol at the start of a URL) into their java.io and java.net equivalents.

File and Datagram Support

Here is an example of opening a file for writing using the GCF:

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

try {
    String url = "file:/logs/mylog.txt";
    OutputConnection conn = 
         (OutputConnection) Connector.open( url,
                                            Connector.WRITE );
    OutputStream out = conn.openOutputStream();
    ..... // write to the output stream
    out.close();
    conn.close();
}
catch( IOException e ){
    // handle error
}

Datagram support is a bit more complex, but quite similar.

Why not just use the java.io and java.net classes directly? The GCF provides a consistent I/O model that works across all J2ME platforms that support the required protocols. If you don't need interoperability with J2SE, use the GCF whenever possible to open your I/O connections.

Using the CDC

Like the CLDC, the CDC is by itself a limited programming platform. Again, 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. The extra classes defined by one or more J2ME profiles are really required to write interactive applications.

Sun has a reference implementation of the CDC hosted on Linux available for download from its website. See Sun's main CDC page for links to it and to the CDC specification.

Next: The Importance of the Mobile Information Device Profile (MIDP)