Verification in Java (JVM)

After the class loader in the JVM loads the byte code of .class file to the machine the Bytecode is first checked for validity by the verifier and this process is called as verification. The verifier performs as much checking as possible at the Linking so that expensive operation performed by the interpreter at the run time can be eliminated. It enhances the performances of the interpreter.

Some of the checks that verifier performs:

• Uninitialized Variables
• Access rules for private data and methods are not violated.
• Method calls match the object Reference.
• There are no operand stack overflows or underflows.
• The arguments to all the Java Virtual Machine instructions are of valid types.
• Ensuring that final classes are not subclassed and that final methods are not overridden
• Checking that all field references and method references have valid names, valid classes, and a valid type descriptor. (source)

If any of these checks fails JVM throws a “java.lang.VerifyError” error. However, we can disable these checks using

java -noverify VerifyGeekFile

One might think how a program could have been manipulated since compiler checks these above validations before generating .class file. But the class file is vulnerable to change before JVM loads it. The bytecode used in the class file is well documented and someone having some knowledge of hex can change the values of hex codes in the .class file thus change the behavior of the program.
For example : The Applets in the web browsers do not download source code instead they download precompiled class files. The browser on your computer determines whether this class file is trustworthy to run or the file have been exploited by a “hostile compiler”.

Consider this Simple Program

// A Java program to demonstrate working
// of the verification process

class VerifyGeekFile
{
    // your initial bank bal
    private float bal;

    // Method to deposit money
    float depositBalance(int bal)
    {
        int myBal = bal;
        this.bal += myBal;
        return this.bal;
    }

    // Driver Method
    public static void main(String[] args)
    {
        VerifyGeekFile obj = new VerifyGeekFile();
        System.out.println(obj.depositBalance(4000));
    }
}

Output
 4000.0

Then execute this in command line to see the byte code in mnemonic form:-

javap -c VerifyGeekFile

Output :

float depositBalance(int);
    Code:
       0: iload_1
       1: istore_2
       2: aload_0
       3: dup
       4: getfield      #2                  // Field bal:F
       7: iload_2
       8: i2f
       9: fadd
      10: putfield      #2                  // Field bal:F
      13: aload_0
      14: getfield      #2                  // Field bal:F
      17: freturn

Here if we change the initial value of myBal or leave it uninitialized using a hex editor, unexpected results are returned. Java verification process protects us from all of these pitfalls.

References:
http://www.informit.com/articles/article.aspx?p=1187967&seqNum=2
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.10