Java Bytecode Verification

This special issue is dedicated to Java bytecode verification. One of the innovative features of the Java language architecture is the definition of a typed assembly language (the Java Virtual Machine Language, JVML) together with a type checker. The purpose of the type checker is to rule out programs that violate Java safety policies, for example, illegal type conversions. However, it turned out that the type system for the JVML is highly nontrivial. Starting with the seminal paper by Stata and Abadi in 1998, research on this type system has led to the publication of around 30 papers and several Ph.D. theses. It is only now that the mathematics is completely understood. Therefore this issue collects together articles by the leading experts in this area that present fully formal treatments of the type system, type checking algorithms, and correctness proofs. The emphasis is very much on precise specifications and proofs. The first paper by Leroy sets the scene by surveying the different approaches to bytecode verification and presenting them in the common framework of data flow analysis. The paper by Freund and Mitchell presents an early and influential approach to sticky points like object initialization and subroutines. The paper by Stärk and Schmid focuses on type correctness of compiled source code and does so in the Abstract State Machine framework. Klein and Wildmoser present machinechecked formalizations and proofs of the whole bytecode level in the Isabelle/HOL system. Basin, Friedrich, and Gawkowski show how to do type checking via model checking. These articles present an excellent example of the power of mathematical models to capture the behavior of software systems precisely, even down to machinechecked proofs. It should be noted that this is not an academic exercise but that existing commercial software still contains incorrect implementations of the bytecode verifier. In April 2003, Microsoft announced a patch to their bytecode verifier because “the ByteCode verifier does not correctly check for the presence of certain malicious code when a Java applet is being loaded.” The severity rating was “Critical”.