This paper describes a specialised logic for proving specifications in the Java Modeling Language (JML). JML is an interface specification language for Java. It allows assertions like invariants, constraints, pre- and post-conditions, and modi able clauses as annotations to Java classes, in a design-by-contract style. Within the LOOP project at the University of Nijmegen JML is used for specification and verification of Java programs. A special compiler has been developed which translates Java classes together with their JML annotations into logical theories for a theorem prover (PVS or Isabelle). The logic for JML that will be described here consists of tailor-made proof rules in the higher order logic of the back-end theorem prover for verifying translated JML specifications. The rules efficiently combine partial and total correctness (like in Hoare logic) for all possible termination modes in Java, in a single correctness formula.

We present a formal executable specification of two crucial JavaCard platform components, namely the Java Card Virtual Machine (JCVM) and the ByteCode Verier (BCV). Moreover, we relate both components by giving a proof of correctness of the ByteCode Verier. Both formalisations and proofs have been machined-checked using the proof assistant Coq.

This paper distinguishes several different approaches to organising a Weakest Precondition (WP) calculus in a theorem prover. The implementation of two of these approaches for Java within the LOOP project is described. This involves the WP-infrastructures in the higher order logic of the theorem prover PVS, together with some associated rules and strategies for automatically proving JML specifications for Java implementations. The soundness of all WP-rules has been proven on the basis of the underlying Java semantics. These WP-calculi are integrated with the existing Hoare logic, and together form a verification toolkit in PVS: typically one uses Hoare logic rules to break a large verification task up into smaller parts that can be handled automatically by one of the WP-strategies.

This paper aims to raise the level of verification challenges by presenting a collection of sequential Java programs with correctness annotations formulated in JML. The emphasis lies more on the underlying semantical issues than on verification.

Ever since their invention 30 years ago, checked exceptions have been a point of much discussion. On the one hand, they increase the robustness of soft ware by preventing the manifestation of unanticipated checked exceptions at run-time. On the other hand, they decrease the adaptability of software bec ause they must be propagated explicitly, and must often be handled even if they cannot be signalled. We show that these problems are caused by a conflict between the exceptional interface of a method and the principle of abstraction. We then solve this conflict by introducing anchored exception declarations, which allow the exceptional behaviour of a method to be declared relative to that of others. We present their formal semantics, along with the necessary rules for ensuring compile-time safety, and give a proof of correctness. We show that ancho red exception declarations do not violate the principle of information hiding when used properly, and provide a guideline for when to use them. We have implemented anchored exception declarations as an extension to the ClassicJava programming language, called Cappuccino.

This paper describes the basic structures in the denotational and axiomatic semantics of sequential Java, both from a monadic and a coalgebraic perspective. This semantics is an abstraction of the one used for the verification of (sequential) Java programs using proof tools in the LOOP project at the University of Nijmegen. It is shown how the monadic perspective gives rise to the relevant computational structure in Java (composition, extension and repetition), and how the coalgebraic perspective o#ers an associated program logic (with invariants, bisimulations, and Hoare logics) for reasoning about the computational structure provided by the monad.

This paper discusses how a subtle interaction between the semantics of Java and the implementation of the JML runtime checker can cause the latter to fail to report errors. This problem is due to the well-known capability of finally clauses to implicitly override exceptions. We give some simple examples of annotation violations that are not reported by the run-time checker because the errors are caught within the program text; even without any explicit reference to them. We explain this behaviour, based on the official Java Language Specification. We also discuss what are the consequences of this problem, and we sketch different solutions to the problem (by adapting the implementation of the JML run-time checker, or by adopting a slightly different semantics for Java). 1.

State Machine Semantics (ASM), Axiomatic Semantics (AS), Context Rewriting semantics (CR), Continuation or monad Semantics (CS), Denotational Semantics (DS), Natural Semantics (NS), Operational Semantics (OS), Structural Operational Semantics (SOS), or a semantic embedding in a higher odrder logic (HOL).

Abstract not found