March 1, 2021
Hot Topics:

The Connected Limited Device Configuration (CLDC)

  • By Eric Giguère
  • Send Email »
  • More Articles »

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: The Connected Device Configuration

Eric Giguère is the author of Java 2 Micro Edition, the first book about J2ME, and co-author of Mobile Information Device Profile for Java 2 Micro Edition, both published by John Wiley & Sons. He works as a software developer for iAnywhere Solutions, a subsidiary of Sybase. For more information about Eric, see his web site or drop him a note at ericgiguere@ericgiguere.com.

# # #

Page 2 of 2

This article was originally published on July 30, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date