After the class loader in the JVM loads the bytecode in the .class file into the machine, the verifier first checks the validity of the bytecode. This process is called verification. The validator performs as many checks on the link as possible to eliminate costly operations performed by the interpreter at runtime. Improve the performance of performers.

Some of the checks that the verifier performs:

• Uninitialized variables do not violate.
• The access rules of private data and methods.
• The method call matches the object reference.
• There is no operand stack overflow or underflow.
• The parameters of all Java virtual machine instructions are to ensure that the final class is not subclassed and the final method is not overwritten.
• Verify that all field references and method references have valid names, valid classes, and valid type descriptors.

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 wonder how the program is manipulated because the compiler checks these verifications before generating the .class file. But the class files are easily changed before the JVM is loaded. The bytecode used in the class file is well documented, and someone with some hexadecimal knowledge can change the value of the hexadecimal code in the .class file to change the behavior of the program. For example: The applet in the web browser does not download the source code. Instead, they download pre-compiled class files. Your computer’s browser will determine whether such files can run reliably, or whether the file has been used by a “malicious 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 the 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 use a hexadecimal editor to make it uninitialized, unexpected results will be returned. The Java verification process protects us from all these pitfalls.