A configuration is a combination of a Java virtual machine and a collection of Application Programming Interfaces (APIs) that target a certain class of device. A configuration provides the basis for one or more profiles on a device. A profile is a set of APIs that enable functionality and take advantage of a more specific class of devices. A configuration defines a base set of APIs that must be implemented on all devices that support the configuration (which will target, for example, low-power devices with small amounts of memory). The profile sitting on top of the configuration must implement the configuration's APIs as well as APIs that are defined as part of the profile for that specific class of those devices (and the profile will target, say, PDAs).
It is important to note that the configuration specifies the capabilities of the underlying virtual machine, but it does not mandate a particular virtual machine. Vendors of profiles and their underlying configurations are free to provide their own virtual machine that conforms to the specification.
The CLDC 1.0 was defined by JSR30 and released in May 2000. It targets devices with a set of basic characteristics. A CLDC device:
is powered by batteries,
has low processing resources,
has low-speed ad hoc network connections,
has 128 KB of memory available for the Java virtual machine and CLDC libraries, and
has at least 32 KB available for the Java runtime and dynamic allocation of objects.
These characteristics define a wide variety of devices, including pagers, mobile phones, and PDAs. The CLDC defines a common basis for these devices in the following areas:
Core Java packages
Virtual machine capabilities
Networking and I/O
It does not cover other areas that may be device-specific, such as the user interface, the application lifecycle, and event handling. These areas are covered by profiles.
The Java virtual machine providing the core of a CLDC adheres to the Java Virtual Machine Specification and the Java Language Specification, with some exceptions. With regard to the Java Language Specification, CLDC includes the following exceptions. Note that no profile or application on top of CLDC can require these things to be present.
No floating point support (i.e., no floating point operations, no floating point literals, types, or values).
Although exceptions are supported, the number of error classes is limited.
With regard to the Java Virtual Machine Specification, the CLDC includes the following exceptions:
No floating point support.
No Java Native Interface (JNI).
No user-defined class loaders.
No thread groups or daemon threads.
No weak references.
Different classfile verification method (a two-phase approach featuring off-device pre-verification).
Modified classfile format and class loading.
The CLDC inherits most of its classes from J2SE, and defines some CLDC-specific classes. The classes inherited from J2SE use the same class and package names. They include those listed in Appendix A, "Packages in CLDC," on page 207. Packages derived from J2SE use the J2SE names, whereas the CLDC-specific packages use the javax.microedition prefix.
The next version of CLDC was defined by JSR139, which was approved in March 2003. The changes in CLDC 1.1 are summarized below:
 Java Specification Request (JSR) is a new specification (or a major change to an existing specification) for the Java platform. The process for the way in which JSRs are raised and developed is defined by the Java Community Process (JCP).
Floating point support has been added. The Float and Double classes have been added to java.lang, and some methods in other classes now allow for floating point values. Affected classes include java.lang.Math, java.io.DataOutputStream, java.io.DataInputStream, and java.util.Random.
Some support for J2SE's weak references. The package java.lang.ref has been added.
The Calendar, Date, and TimeZone classes in java.util are now more consistent with the J2SE versions.
The Error class java.lang.NoClassDefFoundError has been added.
Some minor, but useful, method additions to existing classes, such as the intern() method to the java.lang.String class, and the toString() method to the java.util.Date class.
The full CLDC 1.1 specification is available from http://www.jcp.org/jsr/detail/139.jsp.
The CDC is a superset of CLDC. The CDC includes all APIs defined by the CLDC, including the java.* packages and the javax.microedition.* packages. CDC is designed for devices with more memory (2 MB of memory or more available to the Java platform) and better network connection (up to 9600 bps and beyond). CDC has a PersonalJava heritage, and so PersonalJava applications that do not use AWT (Abstract Window Toolkit). AWT should be quite portable to CDC (AWT capabilities are defined in CDC's profiles).
An implementation of the CDC must include full support for the Java Language Specification and the Java Virtual Machine Specification.
The packages of CDC are designed to be a complete set of APIs to support a virtual machine. They are taken from J2SE 1.3, with deprecated APIs removed. The resulting set of packages is as follows:
java.io?including BufferedReader, BufferedWriter, ObjectInputStream, and ObjectOutputStream
java.net?Classes from J2SE, including URL, URLConnection, InetAddress, and SocketPermission
java.security?Encryption for object serialization. The following is not supported: secure code signing, certificates, keystore, Java Development Kit (JDK) 1.1 Identity, and IdentityScope.
java.text?Minimal support for i18n
java.util?Classes from J2SE, including Array, BitSet, Calendar, LinkedList, Stack, Vector
CDC implementations must support file input/output (I/O) (at least read-only) and datagrams.