After asking whether or not the file looks like a properly formatted class file, the verification algorithm knows where the constant pool is to be found and how many constants are in it. It also knows that all constant tags are valid. (If there was an invalid constant tag, it wouldn't know how many bytes that constant took up, and it would have rejected the file.) Now it can ask the question "Are the constants themselves correctly formed?" That is,
Figure 6.2 depicts part of the constant pool for this class:
.class Foo .super Bar .implements Baz .field field1 LFoo; .method isEven (I)Z ;; ... .end method
Figure 6.2. Are all constant references correct?
In the figure, you can see how the this class and the superclass fields point to Class constants which point to the names Foo and Bar. There is one interface, which points to a Class constant that points to Baz. The field points to the name field1 and the type LFoo; (since it is of type Foo). The method points to the name isEven and the type (I)B (since it takes an integer and returns a boolean). The order of the constants is irrelevant; constants may point to other constants both forward and backward.