J2ME Programming/MIDlet Preverify

A MIDlet is a Java program for embedded devices, more specifically the J2ME virtual machine. Generally, these are games and applications that run on a cell phone.

Introduction

Since class verification in J2SE takes up 50 KB and the lack of space in MIDP devices, the class verification has been broken up to a part that is completed by the developer and apart completed by the Mobile JVM itself. The developer-directed class verification stage is called MIDlet preverification, which occurs after the class is compiled.

What Tasks Preverification Completes

Generally, the preverification task annotates the class files with notes that the small incomplete class verifier in the Mobile VM reads and uses to do a fast class verification to enable the Mobile VM to then run the resulting bytecodes. The resulting bytecodes are valid bytecodes, because the annotations are using attributes of the bytecode to make the notes for the Mobile VM to read in doing its final incomplete class verification.^[1].

JVM Class File Verification

According to The Java Virtual Machine Specification,^[2] class file verification is completed in four passes before full startup of the JVM occurs in running bytecode of an application:

Pass 1

Correct magic number in the first four bytes.
Byte code attributes must be the proper length.
The class file cannot be truncated or have extra bytes at end.
Constant pool must not contain any superficial data.

Pass 2

Ensures that final classes are not subclassed and that the final methods are not overridden.
Checks that every class except Object has a direct superclass.
Ensures that the constant pool meets documented static constraints.
Checks that all field references and method references in the constant pool have valid names, valid classes, and a valid type descriptor.

Pass 3

During linking, the verifier checks the code array of the code attribute by performing a data flow analysis to ensure these items are true:

That the operand stack is always the same size and contains the same types of values.
No local variable is accessed unless it is known to contain a value of an appropriate type.
Methods are invoked with the appropriate arguments.
Fields are assigned only using values of appropriate types.
All opcodes have appropriate type arguments on the operand stack and in the local variable array.

Pass 4

This is the pass where class loading occurs to finalize the class verification process.

Preverification steps

The preverification places a StackMap Attribute, which is a sub attribute of the Code attribute, which describes variable types used and operand stack items.
Inlines all subroutines and removes jumps.^[3]
By default, it generates a class file for the Java code.^[4]

Conclusion

Preverification preverifies the compiled classes by inserting annotations in the StackMap portion of the Code attribute describing variable types used and operand stack items. This and inlining all subroutines and removing jumps reduces the first three passes of the J2SE verification process to something more manageable with the mobile device memory sizes in completing the last fourth pass on the mobile device within the mobile jvm.

Trademark Notices

J2ME, Java and all Java-based marks are trademarks or registered trademarks of ORACLE in the U.S. and other countries.

References

↑ "What is preverification?". What is preverification? Why do I receive error messages from the CLDC/KVM when I do not preverify my class files?.
↑ "VM Spec". The Java Virtual Machine Specification. ISBN 0201432943
↑ ("Ubiquitous Services" (PDF). Ubiquitous Services Services on Mobile Devices.
↑ "J2ME Tutorial, Part 1: Creating MIDlets?". By default, the preverifier will create the preverified version of your class file in a folder called output in the current directory. It will preserve the package structure….