The hardware and software limitations imposed by the devices at which CLDC is targeted make it impractical to support either a full Java virtual machine or a complete set of J2SE core classes. Running a simple "Hello, world" application on the Windows platform requires around 16 MB of memory to be allocated. Contrast this with the minimum platform requirements for CLDC, which call for:
- 128 KB of ROM, flash or battery-backed memory for persistent storage of the Java VM and the class libraries that make up the CLDC platform.
- 32 KB (or more) of volatile memory to be available for runtime allocation. This memory is used to satisfy the dynamic requirements of Java applications, which include class loading and the allocation of heap space for objects and the stack.
In order to support a Java runtime environment with such limited resources, CLDC defines reduced requirements for the virtual machine, the language itself, and the core libraries, details of which we'll describe in the following article.
Other than the memory requirements, CLDC makes few assumptions about its host platform. It does not, for example, assume that the device will have any kind of display or user input mechanism such as a keyboard or a mouse, and it does not require any kind of local storage for application data. These issues are all assumed to be addressed individually by each device vendor. J2ME profiles, of course, place additional requirements that are suitable for the more limited range of devices they are intended for. For CLDC, the number of requirements is minimized in order to maximize the number of platforms on which it can be implemented.
As far as the software environment is concerned, CLDC assumes only that the host device has some kind of operating system that can execute and manage the virtual machine. Although Java is a multithreaded programming environment, it is not necessary for the operating system to have the concept of threads or even to be able to schedule more than one process at any given time. Instead, the virtual machine is required to provide the illusion of a multithreaded environment using whatever native functionality is available to it.
The full specification of CLDC, which was developed under the Java Community Process, can be downloaded from this link.
The CLDC specification defines the features that a VM must have by describing the parts of the full Java Virtual Machine Specification and the Java Language Specification that it is not required to support and the parts to which limitations and qualifications are applied. Sun provides a reference implementation of the CLDC specification that is based on the KVM, a small-footprint VM that satisfies the CLDC requirements. Manufacturers of devices that support CLDC and its profiles are not, however, required to base their products around KVM. Any virtual machine that has the features required by the specification and can work within the resource restrictions of the CLDC environment can be used. In this blog, I will often refer to features of KVM, but, unless I explicitly state the contrary, everything I say also applies to any conforming virtual machine.
The following sections describe the virtual machine and language features that are not supported in a CLDC environment or in which the CLDC behavior is different from that in J2SE.
Floating point support
Since many of the processors used in the target platforms for CLDC do not have floating point hardware, the virtual machine is not required to support floating point operations. In terms of the virtual machine, this means that the byte code operations listed in Table 1 are not implemented.
Table 1. Floating-Point Byte Codes Not Implemented by a CLDC VM
This leads to the following coding restrictions:
- Variables of type float and double and arrays of these types cannot be declared or used.
- Constants of type float and double (i.e., 1.0, 2.0F) cannot be used.
- Method arguments may not be of type float or double.
- Methods may not return double or float
- Objects of type Float and Double cannot be created (and, in fact, these classes do not exist in CLDC -- see Section 2.2 for further details).
Sun does not supply a different version of its Java compiler for use when developing CLDC applications, so it is possible, using a J2SE compiler, to create Java class files that use floating point types and, therefore, violate these rules. However, these class files will be rejected when they are loaded into the CLDC virtual machine during class file verification (see Section 2.1.2 for a discussion of class file verification).
Aside from the floating point restrictions, there are a few other Java language features that are not available to CLDC applications:
The java.lang.reflect package and all of the features of java.lang.class that are connected with reflection are not available. This restriction is applied partly to save memory, but it also saves having to determine whether application code has the privilege to access these features.
Weak references and the java.lang.ref package are not provided because of the memory required to implement them.
Object finalization causes great complexity in the VM for relatively little benefit. Therefore, finalization is not implemented, and the CLDC java.lang.object class does not have a
CLDC provides threads, but it does not allow the creation of a daemon thread (a thread that is automatically terminated when all non-daemon threads in the VM terminate) or thread groups.
Errors and exceptions
J2SE has a large number of classes that represent error and exception conditions. Since Java applications are not, in general, expected to recover from errors (meaning thrown exceptions derived from the class java.lang.Error), most of the classes representing them are not included in the CLDC platform. When such an error occurs, the device is responsible for taking appropriate action instead of reporting it to application code.
Java Native Interface
CLDC does not provide the J2SE JNI feature, which allows native code to be called from Java classes. JNI is omitted partly because it is memory-intensive to implement and partly in order to protect CLDC devices against security problems caused by malicious application code. Further discussion of this issue will be found in Section 2.1.2.
Class loading in J2SE is performed by class loaders, including application-defined class loaders that can implement an open-ended set of mechanisms for locating and loading Java classes. By contrast, the CLDC specification requires implementations to provide their own class loading mechanism that cannot be overridden or extended by application code. Doing so removes the security implications of allowing classes to be loaded from untrusted sources.
CLDC specifies that all VM implementations must be able to load applications packaged in compressed JAR files. It does not, however, rule out additional, device-dependent means of representing or accessing application code, and it does not prescribe any particular means whereby the device would locate and fetch the packaged code. These tasks are delegated to a piece of device-dependent application management software, the nature of which is outside the scope of the specification. Sun's CLDC reference implementation includes an example implementation of this functionality, which it refers to as a Java Application Manager (JAM).
A device is allowed to transform applications presented in any supported external format into an internal format that is more suitable or more efficient for that device. For example, the MIDP for PalmOS product, which includes an implementation of CLDC for the PalmOS platform, accepts applications in the form of a JAR file and converts them to the internal PRC format used by PalmOS for storage on the device. See Section 9.2 for further details.
The IBM J9 virtual machine is another example of a VM that conforms to the CLDC specification. See http://www.embedded.oti.com/ for further information.