ColdFusion MX Professional Projects

Now comes an entirely new step in building your program, preverifying. Because the memory on small devices is so scarce, the MIDP (actually, the CLDC) specifies that bytecode verification be split into two pieces. Somewhere off the device, a preverify step is performed. The device itself is only required to do a lightweight second verification step before loading classes.

As you may recall, bytecode verification is one of the foundation stones of Java's runtime security model. Before a classloader dynamically loads a class, the bytecode verifier checks the class file to make sure it behaves well and won't do nasty things to the JVM. Unfortunately, the code that implements the bytecode verifier is bulky, too large to fit on a small device like a mobile phone. The two-step bytecode verification dictated by the CLDC works like this:

1. Off the device, class files are preverified. Certain checks are performed, and the class file is massaged into a format that the lightweight second-step verifier can easily handle.

2. On the device, the second step of verification is performed as classes are loaded. If a class file has not been preverified, it is rejected.

The MIDP software contains a tool called preverify that performs the first step. On Windows, using Sun's reference implementation, this tool is buried in the build\win32\tools directory in the MIDP installation directory. You may wish to add it to your path.

The preverify tools takes, as input, a class file. It produces a preverified class file. You need to specify a classpath, so the tool can find the class you want to preverify as well as any referenced classes. Finally, you can specify an output directory using the -d option. To overwrite an existing class file with a preverified version, you could do something like this:

preverify -classpath .;\midp\classes -d . Jargoneer

Don't forget that Jargoneer has an inner class, Poster, which must also be preverified:

preverify -classpath .;\midp\classes -d . Jargoneer$Poster

In these examples, the -d option tells preverify to write the preverified class file to the current directory.

If you're using the J2MEWTK instead of the command-line tools, you don't have to worry about explicitly preverifying your class files. The J2MEWTK preverifies class files automatically.