General CLDC Limitations

In order to make the Java feature set suitable for very limited devices such as cellular phones or PDAs, CLDC's developers had to limit the feature set in several ways. This section first describes the general language and virtual machine limitations and some consequences of the missing reflection capabilities. It then discusses the simplified security and highlights some general limitations resulting directly from the limited hardware capabilities of CLDC devices.

General Java Language Limitations

For CLDC, the Java language itself was simplified slightly. The following restrictions hold for the Java language in CLDC:

• No floating-point support (CLDC 1.0 only)

• No reflection

• No thread groups and daemon threads

• No weak references (CLDC 1.0 only)

• Error handling may be limited

• No finalization; CLDC does not support the finalize() method

• No Java Native Interface (JNI)

• No user-defined class loaders

The missing floating-point support is perhaps the most significant limitation because it makes development of calculation or spreadsheet programs very difficult. The MathFP API from Onno Honnes (www.jscience.net) provides fixed-point calculations as a substitute, but fixed-point arithmetic is not a complete replacement for floating-point support.

CLDC supports full exception handling, but limitations may apply to the Error exception classes. The problem is that it is very difficult to handle errors like those that arise from heap exceptions, which may be resolved only by a soft reset of the whole device. Thus, the device may handle errors differently in a manner appropriate to the device without reporting a corresponding exception to Java.

The restrictions concerning user-defined class loaders and the JNI are addressed in the upcoming section “Simplified Security Model.”

Consequences of the Missing Reflection Support

The reflection capabilities of the CLD configuration are very limited. Class.forName() and newInstance() are supported, but you can't work with methods, variables, or constructors at the reflection level.

As a consequence, several other APIs are not available and cannot be implemented for CLDC:

• No class loaders. CLDC supports only the built-in class loader. You can't add custom class loaders.

• No Remote Method Invocation (RMI). RMI relies on full reflection capabilities, so RMI is not possible in CLDC.

• No Jini. Jini depends on RMI, so you can't use it with the CLDC.

• No serialization. Serialization depends on reflection, so serialization is not available in CLDC.

For Jini, a solution could be the surrogate architecture, allowing simple devices to be integrated in a Jini environment. For the missing RMI and serialization capabilities, the explicit serialization of the kSOAP API, described in Chapter 10, “Third Party Libraries,” can provide a replacement, even if it is limited in several ways.

Simplified Security Model

As in J2SE, the Java byte code is verified by the VM before execution in order to prevent security violations resulting from side effects of illegal byte code. In CLDC, the verification process is slightly different from that used in J2SE. CLDC introduces an additional preverification step that simplifies verification of the byte code on the device. The preverification process and its motivation are described in the next section.

For application-level security, J2SE provides security managers for fine-grained access control. Unfortunately, security managers consume too much memory to be included in CLDC devices. For this reason, CLDC provides the simpler sandbox model for application security. The sandbox model means that Java applications run in a closed environment where only APIs known to be safe can be accessed.

The sandbox model means that the following additional restrictions apply:

• The Java Native Interface (JNI) is not available, in order to prevent backdoor access to native functionality that is not exposed through the Java APIs provided with the device.

• User-defined class loaders cannot be created, in order to prevent programmers from overriding the class loading mechanism provided by the VM.

For PDAP, an additional security layer allows the user to grant applications access permissions such as network and personal information management access. By default, PDAP applications are not allowed to establish network connections or access information stored in the device address database or calendar. However, such access can be allowed via the application manager.

Off-Device Preverification

The preverification step was discussed in Chapter 1. This additional step is applied to Java class files after they are generated from the corresponding Java source files. The reason for introducing this additional step, which leads to much confusion for developers, was that the original class file verification performed by the JVM was very expensive in terms of memory and computational power. Basically, the preverification step enriches the class file with hints for the on-device verifier. Thus, the final verification can be performed more efficiently.

Please note that preverification does not mean less security. If you think of the verification process as confirming that a way exists through a labyrinth, then the preverification step marks the way. The way can still be verified in the device, and if the way is not valid, verification will detect that; but preverification lets you avoid the much greater effort involved in finding the way.

General Device Hardware Limitations

General hardware limitations of CLDC devices are

• Limited computing capabilities

• Limited memory

• Limited heap space

The computing power of processors used for mobile phones is usually very limited when compared to desktop systems. Also the memory provided by CLDC devices is very limited. Even worse, for many devices, there is a distinction between persistent (flash) memory and the heap space available, and the heap space usually is only a small fraction of the total memory (32–512KB). So the memory available at runtime may be even more restricted than the memory available in the device.

CLDC 1.1

CLDC 1.1, the “next generation” of the CLDC configuration, which is used in the PDA profile, lifts some of the original CLDC limitations. Namely, CLDC-NG no longer explicitly forbids floating point operations, and weak references are added.