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
Then execute this in command line to see the byte code in mnemonic form:-
javap -c VerifyGeekFile
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.
- Java.util.LinkedList.poll(), pollFirst(), pollLast() with examples in Java
- Java.util.LinkedList.peek() , peekfirst(), peeklast() in Java
- Java.util.concurrent.RecursiveTask class in Java with Examples
- Java.util.concurrent.Phaser class in Java with Examples
- Java.util.function.IntPredicate interface in Java with Examples
- Java.util.function.LongPredicate interface in Java with Examples
- Java.util.function.DoublePredicate interface in Java with Examples
- Java.util.function.BiPredicate interface in Java with Examples
- Java.lang.Short toString() method in Java with Examples
- Java.util.LinkedList.offer(), offerFirst(), offerLast() in Java
- Java.util.Collections.disjoint() Method in java with Examples
- Java.util.concurrent.RecursiveAction class in Java with Examples
- Java lang.Long.lowestOneBit() method in Java with Examples
- Java lang.Long.numberOfLeadingZeros() method in Java with Examples
- Java lang.Long.numberOfTrailingZeros() method in Java with Examples
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to email@example.com. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.
Improved By : Akanksha_Rai