Home : Course Map : Chapter 4 : Java : Supplements :
Class File Verification
JavaTech
Course Map
Chapter 4

Introduction
Inheritance
  Demo 1
Overriding
  Demo 2a
  Demo 2b
this,super
MoreConstructors
  Demo 3
Abstraction
Interface 
  Demo 4
Casting References
MoreAboutArrays
Object class
Class Summary
Exercises

    Supplements
Override/Overload
Annotation-J2SE5.0
Java Security
Class Loading
Class Verifier
SecurityManager
     About JavaTech
     Codes List
     Exercises
     Feedback
     References
     Resources
     Tips
     Topic Index
     Course Guide
     What's New

As part of the class loading process, a thorough verification of the bytecodes takes place to insure that the file holds a valid Java class and does not break any of the rules for class behavior.

The class verification procedure includes basically four steps (though individual JVMs may mix and merge these steps) that check (ref.1):

  1. Structure- examination of the file to see that it form obeys the basic requirements of a class file such as beginning with the magic number (0xCAFEBABE) for Java classes, the length of the file and subsections should be consistent, the version numbers are in the range for the JVM, and so forth.

  2. Semantics - look at individual parts of the class, such as methods and fields, to check that they are well-formed and obey the requirements on the data types involved.

  3. Bytecode - first check the bytecodes to insure that the instructions are valid, in the right order, obey the rules on types and numbers of operands, and so forth. Then a "data-flow analysis" runs to insure that alternate paths to a given instruction always result in a consistent state (for example, the operands should receive assigned values.)

  4. Symbolic references - this step replaces symbolic references, such as the names of other classes methods and fields, with direct references for the JVM execution. This is part of the dynamic binding (or linking) process in which classes are not linked together until they run in the JVM. If a referenced class is not yet load, the JVM, depending on its designers, may load it at this point or wait until it is actually needed in the program processsing. If a class has changed and, for example, a method signature changed from the way it was invoked, the JVM will throw an exception and stop the program.

So we see that deliberately creating Java bytecodes to bypass Java security restrictions requires surmounting very tough entrance roadblocks. If a class follows all of the bytecode rules and loads satisfactorily, what prevents, say, an applet from executing valid but pathological activities such as filling a disk with files or reading files it shouldn't? This is where the SecurityManager (see next page) object comes into the picture.

References & Web Resources

 

Most recent update: Oct. 5, 2005

            Tech
MoreComplexClass
ImprovedHistogram
JavaRandomNums
Vectors & Matrices
Exercises

           Physics
Runge-Kutta 2nd
  Demo 1
Runge-Kutta 4th
  Demo 2
BoundaryVal.Prob
Shooting Method
  Demo 3
Exercises

  Part I Part II Part III
Java Core 1  2  3  4  5  6  7  8  9  10  11  12 13 14 15 16 17
18 19 20
21
22 23 24
Supplements

1  2  3  4  5  6  7  8  9  10  11  12

Tech 1  2  3  4  5  6  7  8  9  10  11  12
Physics 1  2  3  4  5  6  7  8  9  10  11  12

Java is a trademark of Sun Microsystems, Inc.