|  
              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): 
               
                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.
 
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. 
 
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.) 
                
 
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 |