The Connected Limited Device Configuration - Java 2 Micro Edition Application Development - page 25

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 . "
Note
Due to a bug in the original CLDC specification, the .class directive (for example,
String.class ) does not work in CLDC 1.0. However, this issue is fixed in CLDC 1.1 by
adding the NoClassDefFoundError class, required for the compilation process.
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.