Programming Wireless Devices with the Java2 Platform

3.4 Requirements

This section introduces the technical requirements and constraints that were followed in defining the CLDC and MIDP standards. We start with the hardware and software requirements, and then discuss the specific constraints that Java 2 Micro Edition imposes on its configurations and profiles.

It should be noted that the requirements of CLDC and MIDP are different. CLDC is not targeted to any specific device category, and therefore its requirements are broader than those of MIDP. MIDP is focused specifically on two-way wireless communication devices such as cell phones, and the requirements of MIDP are specific to its target market.

3.4.1 Hardware Requirements of CLDC

CLDC is intended to run on a wide variety of small devices. The underlying hardware capabilities of these devices vary considerably, and therefore the CLDC Specification does not impose any specific hardware requirements other than memory requirements. Even for memory limits, the CLDC Specification defines minimum limits only. The actual CLDC target devices may have significantly more memory than the minimum.

The CLDC Specification assumes that the minimum total memory budget available for the Java Virtual Machine, configuration libraries, profile libraries, and the applications is at least 192 kilobytes. More specifically, it is assumed that:

• At least 160 kilobytes of non-volatile^[3] memory is available for the virtual machine and CLDC libraries.

  ^[3] The term non-volatile is used to indicate that the memory is expected to retain its contents between the user turning the device "on" or "off." For the purposes of the CLDC Specification and MIDP Specification, it is assumed that non-volatile memory is usually accessed in read mode and that special setup might be required to write to it. Examples of non-volatile memory include ROM, flash, and battery-packed SDRAM. The CLDC Specification or MIDP Specification do not define which memory technology a device must have, nor do they define the behavior of such memory in a power-loss scenario.

• At least 32 kilobytes of volatile^[4] memory is available for the virtual machine runtime (for example, the object heap).

  ^[4] The term volatile is used to indicate that the memory is not expected to retain its contents between the user turning the device "on" or "off." For the purposes of the CLDC Specification and MIDP Specification, it is assumed that volatile memory can be read from and written to directly. The most common type of volatile memory is DRAM.

The ratio of volatile to non-volatile memory in the total memory budget can vary considerably depending on the target device and the role of the Java platform in the device. If the Java platform is used strictly for running system applications that are built in a device, then applications can be prelinked and preloaded, and a very limited amount of volatile memory is needed. If the Java platform is used for running dynamically downloaded content, then devices will need a higher ratio of volatile memory.

3.4.2 Hardware Requirements of MIDP

The MIDP expert group defined a Mobile Information Device (MID) to be a device that should meet the following minimum requirements:

• Memory:

  • 256 kilobytes of non-volatile memory for the MIDP components^[5]

    ^[5] Memory requirements cited here are for MIDP components only. MIDP runs on top of CLDC, so the static size of the CLDC implementation must be added to this figure.

  • 8 kilobytes of non-volatile memory for application-created persistent data

  • 128 kilobytes of volatile memory for the virtual machine run time (for example, the object heap)

• Display:

  • Screen-size: 96x54

  • Display depth: 1-bit

  • Pixel shape (aspect ratio): approximately 1:1

• Input:

  • One or more of the following user-input mechanisms (see Figure 3.3):

    - "one-handed keypad"

    - "two-handed keyboard"

    - touch screen

• Networking:

  • Two-way, wireless, possibly intermittent, with limited bandwidth

• Sound:

  • The ability to play tones, either via dedicated hardware, or via software algorithm.

3.4.3 Software Requirements of CLDC

Like the hardware capabilities, the system software in CLDC target devices varies considerably. For instance, some of the devices might have a full-featured operating system that supports multiple, concurrent operating system processes and a hierarchical file system. Many other devices might have extremely limited system software with no notion of a file system. Faced with such variety, CLDC makes minimal assumptions about the underlying system software.

Generally, the CLDC Specification assumes that a minimal host operating system or kernel is available to manage the underlying hardware. This host operating system must provide at least one schedulable entity to run the Java virtual machine. The host operating system does not need to support separate address spaces or processes, nor does it have to make any guarantees about the real-time scheduling or latency behavior.

3.4.4 Software Requirements of MIDP

For devices meeting the MIDP hardware requirements described in previous subsection, there is a broad range of possible system software capabilities. Unlike the consumer desktop computer model where there are large, dominant system software architectures, the Mobile Information Device (MID) space is characterized by a wide variety of system software. For example, some MIDs might have a full-featured operating system that supports multiprocessing^[6] and hierarchical file systems, while other MIDs might have small, thread-based operating systems with no notion of a file system. Faced with such variety, the MIDP Specification, like the CLDC Specification, makes minimal assumptions about system software. These requirements are as follows:

^[6] The ability to run multiple, concurrent processes, each with a separate and distinct memory map.

• A minimal kernel to manage the underlying hardware (that is, handling of interrupts, exceptions, and minimal scheduling). This kernel must provide at least one schedulable entity to run the Java Virtual Machine. The kernel does not need to support separate address spaces (or processes) or make any guarantees about either real-time scheduling or latency behavior.

• A mechanism to read and write from non-volatile memory to support the MIDP persistence APIs discussed in Chapter 14.

• Read and write access to the device's wireless networking to support the MIDP networking APIs discussed in Chapter 15.

• A mechanism to provide a time base for use in time-stamping the records written to persistent storage and to provide the basis of the timer APIs defined in Section 20.1, "Timer Support."

• A minimal capability to write to a bit-mapped graphics display.

• A mechanism to capture user input from one (or more) of the three input mechanisms previously discussed.

3.4.5 J2ME Requirements

CLDC is defined as a Java 2 Micro Edition (J2ME™) configuration. MIDP is defined as a Java 2 Micro Edition profile. The rules for J2ME configurations and profiles impose certain additional constraints on the CLDC and MIDP specifications:

• A J2ME configuration shall only define a minimum complement or the "lowest common denominator" of Java technology. All the features included in a configuration must be generally applicable to a wide variety of devices. Features specific to a certain vertical market, device category, or industry should be defined in a profile. This means that the scope of the Connected, Limited Device Configuration Specification is limited and must generally be complemented by profiles.

• Since the goal of the J2ME configurations is to guarantee portability and interoperability between various kinds of resource-constrained devices, the configurations do not define any optional features. This limitation has a significant impact on what can be included in the CLDC Specification and what should not be included. More device-specific or optional functionality should generally be avoided, but, if necessary, such functionality must be defined in J2ME optional packages, manufacturer-specific licensee open classes (also known as OEM-specific classes), rather than in the J2ME configuration or profile specifications.

• A J2ME configuration specification shall generally define a subset of the Java technology features and libraries provided by the Java 2 Platform, Standard Edition (J2SE). Consequently, rather than providing a complete description of all the supported features, the CLDC Specification shall only define the variances and differences compared to the full Java Language Specification (JLS) and Java Virtual Machine Specification (JVMS). If something is not explicitly specified in the CLDC Specification, then it is assumed that a virtual machine conforming to the CLDC Specification shall comply with the JLS and JVMS.

Note that the absence of optional features in CLDC and MIDP does not preclude the use of various implementation-level optimizations. For instance, at the implementation level, alternative bytecode execution techniques (for example, Just-In-Time compilation) or application representation techniques can be used as long as the observable user-level semantics of the implementation remain the same as defined by the CLDC Specification and MIDP Specification.