Second layer:

The second layer of Java security includes careful verification of Java class files- involving the virtual machine bytecodes which represent the compiled versions of methods-as they are loaded into the virtual machine. This verification ensures which a garbled class files won't cause an error inside the Java interpreter itself, but it also ensures in which the basic language safety is not violated.  The rules about proper language behavior that were written into the language specification are good, but it's also important to make sure that those rules aren't broken. By Checking everything in the compiler isn't good sufficient, since it's possible for someone to write a completely new compiler which omits those checks. By that reason, the Java library carefully checks and verifies the bytecodes of every class which is loaded into the virtual machine to make sure that those bytecodes obey the rules. A few of the rules, such as bounds checking on references to array elements, are in fact implemented in the virtual machine, then no real checks are necessary. Other rules, therefore, must be checked carefully. One particularly significant rule which is verified rigorously is which objects must be true to their type-an object that is created as a particular type must never be able to masquerade as an object of a few incompatible types. Or else, there would be a serious loophole through that explicit security checks could be bypassed.

This verification procedure doesn't mean in which Java code can't be compiled to native machine code. As long as the validation is performed on the bytecodes first, a native compiled version of a class is still secure. JIT ("Just-in-time") compilers run within the JVM, compiling bytecodes to native code as classes are loaded, only after the bytecode verification stage. That compilation step doesn't commonly take many times and the resulting code runs much faster.