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

Language runtime systems are increasingly being embedded in systems to support runtime extensibility via mobile code. Such systems raise a number of concerns when the code running in such systems is potentially buggy or untrusted. While sophisticated access controls have been designed for mobile code and are shipping as part of commercial systems such as Java, there is no support for terminating mobile code short of terminating the entire language runtime. This paper presents a concept called “soft termination ” which can be applied to virtually any mobile code system. Soft termination allows mobile code threads to be safely terminated while preserving the stability of the language runtime. In addition, function bodies can be permanently disabled, thwarting attacks predicated on system threads eventually calling untrusted functions. We present a formal design for soft termination and an implementation of it for Java, built using Java bytecode rewriting, and demonstrating reasonable performance (3-25% slowdowns on benchmarks).

We present an operational semantics, type system, and a proof of type soundness for a substantial subset of Java. The subset includes interfaces, classes, inheritance, field hiding, method overloading and overriding, arrays with associated dynamic checks, 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. Thus, 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 ...

The contribution of the paper is twofold. First, we define a general notion of type system equipped with an entailment relation between type environments; this generalisation serves as a pattern for instantiating type systems able to support separate compilation and interchecking of Java-like languages, and allows a formal definition of soundess and completeness of inter-checking w.r.t. global compilation. These properties are important in practice since they allow selective recompilation. In particular, we show that they are guaranteed when the type system has principal typings and provides sound and complete entailment relation between type environments.

ing with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works, requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept, ACM Inc., 1515 Broadway, New York, NY 10036 USA, fax +1 (212) 869-0481, or permissions@acm.org. 2 \Delta Philip W. L. Fong and Robert D. Cameron (1) Interleaved logic. Sun's implementation interleaves bytecode verification and loading. Java programs are composed of classes, each being loaded into the JVM separately. In the middle of verifying a class X, a new class Y may need to be loaded in order to provide enough information for the verification of X to proceed. For example, in order for the verifier to make sure that a method may throw an "ArithmeticException", it must check whether "ArithmeticException" is a subclass of the class "Throwable". As a result, the loader has to be invoked to bring in "ArithmeticException" ...

We define a formal notion, called compilation schema, suitable for specifying di#erent possibilities for performing the overall process of Java compilation, which includes typechecking of source fragments with generation of corresponding binary code, typechecking of binary fragments, extraction of type information from fragments and definition of dependencies among them. We consider three compilation schemata of interest for Java, that is, minimal, SDK and safe, which correspond to a minimal set of checks, the checks performed by the SDK implementation, and all the checks needed to prevent run-time linkage errors, respectively. In order to demonstrate our approach, we define a kernel model for Java separate compilation and execution, consisting in a small Java subset, and a simple corresponding binary language for which we provide an operational semantics including run-time verification. We define a safe compilation schema for this language and formally prove type safety.

The promises of object-orientation and distributed computing could be delivered if the software we needed were written in stone. But it isn't, it changes. The challenge of distributed object-oriented maintenance is to find a means of evolving software, which already has a distributed client base.

The distributed development and maintenance paradigm for component delivery is fraught with problems. One wants a relationship between developers and clients that is autonomous and anonymous. Yet components written in languages such as C++ require the recompilation of all dependent subsystems when a new version of a component is released. The design of Java's binary format has side-stepped this constraint, removing the need for total recompilation with each change. But the potential is not fulfilled if programs have to be stopped to swap in each new component.

The component-based model of code execution imposes some requirements on the software components themselves, and at the same time lays some constraints on the modern run-time environment. Software components need to store descriptive metadata, and the run-time system must access this `reflectively' in order to implement dynamic linking. Software components also undergo dynamic evolution whereby a client component experiences the effects of modifications, made to a service component even though these occurred after the client was built.

We provide a modular high-level definition of the Java Virtual Machine (JVM) architecture. We decompose the machine into three components -- the loader, the bytecode verifier and the interpreter -- each for a hierarchy of four stepwise refined JVM program layers. These layers naturally correspond to the structuring of Java into sublanguages with imperative, procedural, object-oriented and exception handling features. We give our definitions in terms of Abstract State Machines, which have a simple but precise semantic foundation. As a consequence our JVM models can be verified and validated by machine supported mathematical analysis and standard simulation techniques. Furthermore, due to their abstract nature, the models can serve as a platform independent basis for the evaluation and comparison of different JVM implementations.