Understanding The Connected Limited Device Configuration (CLDC)
By Eric Giguere
July 30, 2002
Originally published on Developer.com
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:
- The capabilities of the Java virtual machine (VM), which is not a full-featured Java VM.
- A very small subset of the J2SE 1.3 classes.
- 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)
User groups have permission to reprint this article for free
as described on the copyrights page.
|