Building MIDlets - Beginning J2ME: From Novice to Professional - page 17

javac -bootclasspath \midp\classes Jargoneer.java

You will need to adjust the path to classes if you installed the MIDP reference implementation
in a different location.

Preverifying Class Files
Now comes an entirely new step in building your program, preverifying . Because the memory
on small devices is so scarce, MIDP (actually, 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.
If you are using the J2ME Wireless Toolkit, you don't have to worry about preverifying class
files, and you may not even notice that it's happening when you click the Build button. If you'd
like to understand more about preverifying, read the rest of this section. Otherwise, you can
just skip ahead.
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 CLDC dictates a two-step bytecode verification:

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.
This format is really just a regular class file, with some additional data attached by the
preverifier.

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 reference implementation and the J2ME Wireless Toolkit contain a tool called
preverify that performs the first step.
The preverify tools takes, as input, a class file. It produces a preverified class file. You need
to specify a classpath so that 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 over-
write an existing class file with a preverified version, you could do something like this:

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

In this example, the -d option tells preverify to write the preverified class file to the
current directory. Don't forget about inner classes, which must also be preverified.

■ Note Splitting bytecode verification into two pieces like this has important security ramifications. Devices
should only download code from trusted sources, using a secure method because some bytecode verification
is performed off the device. (See Chapter 3 for more information on MIDlet suite security.) An attacker could
supply malicious code that appeared to be preverified, even if it violated the rules of the full J2SE bytecode
verifier. To the MIDP second-step verifier, the code would look okay and it would be loaded and run.