Preverification

 
Preverification
The next step after compilation is to preverify the .class files you just compiled. To do so, issue
the following command:
$ preverify -classpath "../../lib/midpapi.zip;tmpclasses" -d classes
\
tmpclasses
$
If you're using the J2ME Wireless Toolkit, you must separate the class path elements with
semicolons, and you must quote them if you're using a Unix shell in order to avoid the shell
interpreting the semicolon. The class path elements represent the directories from which classes
are to be loaded. The class path element separator—a semicolon in this case—is platform specific.
The -d argument indicates the destination directory to which the preverified output classes
produced by this command are to be written. Finally, the trailing directory name, tmpclasses,
indicates the location from which to get the unverified class files that were produced from the
previous compilation step.
Running the above preverify command creates preverified .class files in the classes
directory, as you specified:
$ ls -l classes/
total 0
-rw-r--r-- 1 vartan None 922 HelloWorld.class
$
The preverify command is a class file preverification tool that is used as part of the class file
verification process. Class file verification in CLDC, as in J2SE, is the process of verifying the
validity of Java class files and rejecting invalid ones. Unlike the J2SE verification process,
however, class file verification in CLDC involves two-steps:
1. Phase 1— off-device preverification
2. Phase 2— in-device verification
The use of the preverify command that you just experienced represents the off-device
preverification phase—Phase 1—of this two-step verification process. In a real environment, this
first phase usually occurs on the server from which MIDP applications are downloaded to mobile
devices. Typically, the server performs this step before it makes an application available for
download.
The reason for this new verification process is that the conventional J2SE class file verifier
requires more memory and processing power than typical mobile devices can realistically supply.
It uses about 50 KB of binary code space and 30 to 100 KB of dynamic RAM at runtime. The new
CLDC verifier requires much less RAM and is much more efficient. For typical class files, the
CLDC verifier uses only about 10 KB of code space and requires only 100 bytes of dynamic RAM
at runtime.
17
The new verifier can achieve these efficiency gains because of the new algorithm it uses. This new
algorithm, however, requires the presence of special attributes in each Java class file. The
preverifier writes these new attributes to each Java class file. The verifier then uses the attributes
generated by the preverifier. The new class files are about 5 percent larger than their unmodified
versions.
The preverifier performs two tasks:
• It makes all subroutine calls "inline," replacing each call to methods that contain the byte
codes jsr, jsr_w, ret, and wide ret with semantically equivalent code that doesn't
contain these instructions.
• It inserts stack map attributes into what is otherwise a normally formatted Java class file.
These new class files are still valid J2SE class files. That is, the new stack map attributes are
simply ignored by the J2SE verifier. The inclusion of stack map attributes has been implemented
with the extensible attribute mechanism, which is supported by the Java class file format defined
by the standard Java virtual machine. This means that CLDC class files are upwardly compatible
with the J2SE virtual machine.
The attributes that the preverifier writes to CLDC class files are called stack map attributes. Stack
map attributes are defined by a StackMap_attribute data structure. These attributes are
subattributes of the Code attribute defined and used by the conventional J2SE virtual machine.
The name stack map reflects the attribute's nature as a description of the type of a local variable or
operand stack item. The name is so chosen because these items always reside on the interpreter's
stack.
The Code_attribute type is another type defined by the standard virtual machine. It defines
the Code attribute used by the standard J2SE VM. For complete descriptions of these structures,
please refer to the Java Virtual Machine Specification, which is referenced in the References
section at the back of this book. The CLDC preverifier defines the following
Stackmap_attribute structure that defines the stack map derivative type as follows:
StackMap_attribute
{
u2 attribute_name_index;
u4 attribute_length;
u2 number_of_entries;
{
u2 byte_code_offset;
u2 number_of_locals;
ty types_of_locals[number_of_locals];
u2 number_of_stack_items;
ty types_of_stack_items[number_of_stack_items];
} entries [number_of_entries];
}
For further details about the definition and function of each of these fields, please refer to the
Connected, Limited Device Configuration Specification, which is also referenced in the
References section of this book.