The Connected Device Configuration (CDC)

 
The Connected Device Configuration (CDC)
The Connected Device Configuration (CDC) intends to capture just the essential capabilities of
each kind of device in the category of devices it targets, namely, devices with 2 MB or more of
total memory, including both RAM and ROM.
As you saw in Figure 1.1, a configuration specifies both the set of Java VM features that are
supported and a set of class libraries. The CDC specifies the use of the full Java 2 platform VM,
which, in this context, is called the Compact Virtual Machine (CVM).
The CVM. Although the CVM supports the same features as the J2SE VM, it is designed for
consumer and embedded devices. This means that the standard J2SE VM has been reengineered to
suit the constraints of limited-resource devices. The features of the resulting offspring CVM are:
• advanced memory system
• small average garbage collection pause times
• full separation of VM from memory system
• modularized garbage collectors
• generational garbage collection
In particular, the CVM has been engineered to offer the following features:
• portability
• fast synchronization
• execution of Java classes out of read-only memory (ROM)
• native thread support
• small class footprint
• provision of interfaces to and support for real-time operating system (RTOS) services
• mapping Java threads directly to native threads
• support for all Java 2, v1.3 VM features and libraries: security, weak references, Java
Native Interface (JNI), Remote Method Invocation (RMI), Java Virtual Machine
Debugging Interface (JVMDI)
CDC Class Libraries. The CDC specifies a minimal set of class libraries and APIs. It supports
the following standard Java packages:
• java.lang— Java VM system classes
• java.util— underlying Java utilities
• java.net— Universal Datagram Protocol (UDP) datagram and input/output (I/O)
• java.io— Java file I/O
• java.text— very minimal support for internationalization (I18N—see chapter 9)
• java.security— minimal fine-grain security and encryption for object serialization
As you can see, these APIs do not include the full set of Java 2 software development kit (SDK)
packages. In some cases, these packages and classes are subsets of the Java 2 SDK packages and
classes. Resource constraints dictate removal of the remainder of the J2SE classes and APIs. Also,
all deprecated J2SE APIs are removed. Table 1.1 lists the full set of packages supported by the
CDC.
Table 1.1. CDC Packages
CDC Package Name Description
java.io Standard I/O classes and interfaces
java.lang VM classes
5
java.lang.ref Reference classes
java.lang.reflect Reflection classes and interfaces
java.math Math package
java.net Networking classes and interfaces
java.security Security classes and interfaces
java.security.cert Security certificate classes
java.text Text package
java.util Standard utility classes
java.util.jar Java Archive (JAR) utility classes
java.util.zip ZIP utility classes
javax.microedition.io CDC generic connection framework classes and interfaces
The Foundation Profile. A configuration, together with a profile, creates a J2ME runtime
environment. The system-level features and services supported by a configuration are more or less
hidden from the application developer. In reality, the application developer is prohibited from
accessing them directly. If this were not the case, the application would not be considered J2ME
compliant.
From the programmer's perspective, a profile is required to do "useful" work. A profile defines the
layer that contains the APIs that the programmer usually manipulates. The J2ME creators initially
defined one CDC profile, the Foundation Profile, which is based on the J2SE v1.3 release. It was
designed by standard committee through the Java Community Process, by an expert group of
companies in the consumer electronics industry. The Foundation Profile contains the J2SE
packages listed in Table 1.2.
The list of packages above looks exactly like the list that comprises the CDC. In fact, they are the
same. To say that the Foundation Profile contains these packages really means that they are
available to the Foundation Profile. The intention is that the Foundation Profile be used with the
CDC. The delineation between the profile and the configuration is a conceptual one, not a physical
one.
Notice that the whole java.awt Abstract Window Toolkit (AWT) and javax.swing Swing
package hierarchies that define the J2SE graphical user interface (GUI) APIs are absent from the
supported packages. If an application needs a GUI, an additional profile would be required.
Profiles can be built on top of one another. An implementation of the J2ME platform, however,
can contain only one configuration.
The lack of GUI support in the Foundation Profile has less impact for the family of shared,
constantly connected network devices such as TV set-top boxes than it does for personal, mobile
devices, which are served by the second J2ME configuration, the CLDC.
In general, the decision to include or omit features and libraries from a configuration or profile is
based on their footprints, static and dynamic resource requirements, and security requirements.
Table 1.2. Foundation Profile Packages
Foundation Profile
Package Name Description
java.lang Rounds out full java.lang.* J2SE package support for the
Java language (Compiler, UnknownError)
java.util Adds full zip support and other J2SE utilities
(java.util.Timer)
java.net Adds TCP/IP Socket and HTTP connections
6
java.io Rounds out full java.io.* J2SE package support for Java
language input/output (Reader and Writer classes)
java.text Rounds out full java.text.* J2SE package support for
internationalization (I18N): Annotation, Collator,
Iterator
java.security Adds code signing and certificates
Personal Profile. The Personal Profile specification was created through the Java Community
Process, resulting in JSR-62. The Personal Profile provides an environment with full AWT
support. The intention of its creators is to provide a platform suitable for Web applets. It also
provides a J2ME migration path for Personal Java applications.
Personal Profile version 1.0 requires an implementation of the Foundation Profile version 1.0. It is
a superset of the Personal Basis Profile version 1.0. Personal Profile is a subset of the J2SE
version 1.3.1 platform, however, which makes Personal Profile applications upward compatible
with J2SE version 1.3.1.
Table 1.3 lists the packages that comprise Personal Profile version 1.0.
Table 1.3. Personal Profile Packages
Personal Profile Package
Name
Description
java.applet Classes needed to create applets and those used by
applets
java.awt Classes for creating AWT UI programs
java.awt.datatransfer Classes and interfaces for transferring data within and
between applications
java.awt.event Classes and interfaces for AWT event handling
java.awt.font Classes and interface for font manipulation
java.awt.im Classes and interfaces for defining input method editors
java.awt.im.spi Interfaces that aid in the development of input method
editors for any Java runtime environment
java.awt.image Classes for creating and modifying images
java.beans Classes that support JavaBean development
javax.microedition.xlet Interfaces used by J2ME Personal Profile applications
and application managers for communication
RMI Profile. The RMI Profile is a profile designed for platforms that support the CDC
configuration. It has been defined by JSR-66 by various companies participating through the Java
Community Process.
The RMI Profile requires an implementation of the Foundation Profile and is built on top of it.
RMI Profile implementations must support the following features:
• full RMI call semantics
• marshaled object support
• RMI wire protocol
• export of remote objects through the UnicastRemoteObject API
• distributed garbage collection and garbage collector interfaces for both client and server
side
• the activator interface and the client side activation protocol
• RMI registry interfaces and export of a registry remote object
7
The RMI profile supports a subset of the J2SE v1.3 RMI API. The following interfaces and
features are part of the J2SE v1.3 RMI specification and public API, but support for these
interfaces and functionality is omitted from the RMI profile specification because of limitations on
device processing power, network performance, and throughput:
• RMI through firewalls and proxies
• RMI multiplexing protocol
• implementation model for an "activatable" remote object
• deprecated methods, classes, and interfaces
• support for the RMI v1.1 skeleton/stub protocol
• stub and skeleton compiler
Support for the following J2SE RMI v1.3 properties is omitted:
• java.rmi.server.disableHttp
• java.rmi.activation.port
• java.rmi.loader.packagePrefix
• java.rmi.registry.packagePrefix
• java.rmi.server.packagePrefix