Java Reference
In-Depth Information
A device with the CLDC is quite primitive; it's missing many of the classes you'd
expect to find that permit application development (such as user-interface widgets,
network connectivity, and the like). Instead, the implementation leaves those details
to profiles atop the CLDC, and focuses instead on reducing memory and CPU foot-
print to the absolute minimum necessary for the Java environment. One area
obviously affected is the nature of the libraries included in the CLDC; many Java SE
classes are simply not available in the CLDC, and of those that are available, not all
methods may be available. This is especially true for collections, where only three
classes and one interface are available. (For more details on exactly what
is
supported,
see Chapter 2.)
While the JVM historically absorbs the entire burden of Java bytecode verification,
this is not the case for the CLDC. Because bytecode verification is expensive both in
terms of processor and memory, the responsibility of bytecode verification is shared
between the developer and the KVM running on the mobile device. As part of the build
process, you run a tool called preverify that inlines subroutines in each class file (remov-
ing certain bytecodes in the process) and adds information about variables on the stack
and their types. At runtime, the KVM uses this additional information to complete the
bytecode verification prior to execution.
■
Note
Two-pass preverification obviously brings with it potential security issues, because a malicious
developer could inject code that appears to be preverified but does not meet all of the standards required by
the CLDC. To address this, CLDC applications are typically downloaded from trusted sources; moreover, the
profile used with the CLDC—the MIDP—adds code signing, so that a Java implementation can verify the
originator of the code being executed and provide an appropriate level of trust.
But security changes don't end there. The sandbox model, familiar to applet
developers from the early days of Java, plays a much greater role in the CLDC, where
applications are sandboxed from each other as well as the host operating system. Each
application runs in an environment where the only facilities it can access are those
classes in its own distribution and the local classes provided by the device's configura-
tion, profile, and optional packages. The download, installation, and management of
other Java applications are also inaccessible, preventing one application from affecting
another. Finally, there is no facility for creating native methods, closing potential holes
between the sandbox and the native platform.
Another key feature of the CLDC is the Generic Connection Framework (GCF),
which defines a hierarchy of interfaces that generalize port connections. The resulting
hierarchy provides a single set of classes you use to connect to any network or remote
port, including Transmission Control Protocol over IP (TCP/IP), User Datagram
Protocol (UDP), and serial ports, just to name a few. The GCF is defined in the
javax.microedition.io
package.
