Introduction to the Java 2 Micro Edition (J2ME) Platform
Configurations and Profiles
A configuration specifies three basic elements:
- a set of Java programming language features
- a set of Java virtual machine features
- a set of supported Java libraries and application programming interfaces (APIs)
The creators of J2ME have defined only two configurations to avoid a fragmented landscape of incompatible platforms. The two configurations that exist currently represent the two categories of pervasive devices you saw earlier in this chapter, namely:
- personal, intermittently connected mobile devices—supported by the Connected, Limited Device Configuration (CLDC)
- constantly connected network devices—supported by the Connected Device Configuration (CDC)
Theoretically, a configuration could specify the very same support as the J2SE platform libraries. This is unlikely in the real world because, as you now know, J2ME is targeted at devices that are far less powerful than desktop computers.
Configuration specifications require that all Java classes adapted from J2SE be the same as or a proper subset of the original J2SE class. That is, a class cannot add methods not found in the J2SE version. Configurations can include additional classes in their specifications, however; configurations themselves are not necessarily proper subsets of J2SE. Both configurations that have been defined to date add classes not present in J2SE in order to address device attributes and constraints.
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 IO classes and interfaces |
| java.lang | VM classes |
| 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 |
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 |
| 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 Foundation 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
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
Page 2 of 4
Comment and Contribute