. In this chapter we formally specify a subset of Java Virtual Machine (JVM) instructions for objects, methods and subroutines based on the official JVM Specification, the official Java Language Specification and Sun's JDK 1.1.4 implementation of the JVM. Our formal specification describes the runtime behaviors of the instructions in relevant memory areas as state transitions and most structural and linking constraints on the instructions as a static typing system. The typing system includes a core of the Bytecode Verifier and resembles data-flow analysis. We state some properties based on our formal specification and sketch the proofs. One of these properties is that if a JVM program is statically well-typed with respect to the typing system, then the runtime data of the program will be type-correct. Our formal specification clarifies some ambiguities and incompleteness and removes some (in our view) unnecessary restrictions in the description of the official JVM Specification. 1 Intr...

We propose a calculus describing compilation and linking in terms of operations on fragments, i.e. compilation units, without reference to their specific contents. We believe this calculus faithfully reflects the situation within modern programming systems. Binary compatibility in Java prescribes conditions under which modification of fragments does not necessitate recompilation of importing fragments. We apply our calculus to formalize binary compatibility, and demonstrate that several interpretations of the language specification are possible, each with different ramifications. We choose a particular interpretation, justify our choice, formulate and prove properties important for language designers and code library developers. 1. Introduction Separate compilation and linking, although supported by most language implementations, is under-specified in most language descriptions [3]. In the traditional arrangement in languages such as Ada [22, 4] or Modula-2 [23], the compiler checks ...

Isabelle/HOL has recently acquired new versions of definitional packages for inductive datatypes and primitive recursive functions. In contrast to its predecessors and most other implementations, Isabelle/HOL datatypes may be mutually and indirect recursive, even infinitely branching. We also support inverted datatype definitions for characterizing existing types as being inductive ones later. All our constructions are fully definitional according to established HOL tradition. Stepping back from the logical details, we also see this work as a typical example of what could be called "Formal-Logic Engineering". We observe that building realistic theorem proving environments involves further issues rather than pure logic only. 1

Type compatibility can be defined based on name equivalence, that is, explicit declarations, or on structural matching. We argue that component software has demands for both. For types expressing individual contracts, name equivalence should be used so that references are made to external semantical specifications. For types that are composed of several such contracts, the structure of this composition should decide about compatibility. We introduce

this paper does not obey the subsumption rule. For instance, the type of aPhil.like is Phil, but the type of pascal.like

Java bytecode provides a portable representation for programs that allows executable content to be embedded in web pages, transferred across a network, and executed on a remote user's machine. Features like these provide many new opportunities for developers, but special precautions must be taken to protect users from badly-behaved programs, which might otherwise destroy valuable data or compromise their privacy. To avoid such problems, bytecode programs from untrusted sources must be verified before they are used. If a program passes, then it should be well-behaved, and should not be able to subvert the other security mechanisms of the Java platform. However, if a program fails, then it will be rejected. Clearly, to be sure that it is effective, we need a precise way to understand bytecode verification. This paper describes the main features of a formal specification for Java bytecode that allows us to reason about the correctness of Java implementations, and to guarantee safety prope...

We outline a proof of type soundness for Java exceptions and exception handling. We distinguish between normal execution, where no exception is thrown -- or, more precisely, any exception thrown is handled -- and abnormal execution, where an exception is thrown and not handled. The type system distinguishes normal types which describe the possible outcomes of normal execution, and abnormal types which describe the possible outcomes of abnormal execution. The type of a term consists of its normal type and its abnormal type. With this set-up we prove subject reduction. The meaning of our subject reduction theorem is stronger than usual: it guarantees that normal execution returns a value of a type compatible with the normal type of the term, and that abnormal execution throws an exception compatible with the abnormal type of the term. 1 Introduction Exceptions and exception handling aim to support the development of robust programs with reliable error detection, and fast error handling ...

Higher-order logics are expressive tools for tasks ranging from formalizing the foundations of mathematics to large-scale software verification and synthesis. Because of their complexity, proofs in higher-order logics often use a combination of interactive proving together with computationally-intensive tactic applications that perform proof automation. As problems and proof automation become more sophisticated, these proofs represent substantial investments -- each interactive step may represent several hours of design time. We present an implementation of a distributed proving architecture to address the problems of speed, availability, and reliability in tactic provers. This architecture is implemented as a module in the MetaPRL logical framework. The implementation supports arbitrary process joins and allbut-one process failures at any time during a proof. Proof distribution is completely transparent; the existing tactic base is unmodified.

This report describes the programming and interface specification language of the Java Interactive Verification Environment Jive. The Jive system is a prototype implementation of a logic-based programming-environment for an object-oriented programming language. Logic-based programming-environments are language-dependent software development tools that support formal specification and verification. We summarize the properties of an ideal programming language for the prototype and argue that Java is a good candidate. The design of the supported Java subset is discussed and a formal definition of the abstract syntax is presented. Program specifications are denoted in an interface specification language. This report discusses the design of the Jive interface specification language and presents its abstract syntax. An example program illustrates the application of the programming and the interface specification language. Contents 1 Introduction 4 2 Programming Language 6 2.1 Design Conce...