SRC Technical Note

2000-004

October 12, 2000


ESC/Java Quick Reference

Silvija Seres, June 1999

Revised by K. Rustan M. Leino and James B. Saxe, October 2000


Compaq
Compaq Computer Corporation
Systems Research Center
130 Lytton Avenue
Palo Alto, CA 94301
http://research.compaq.com/SRC/


Copyright © 1999, 2000 Compaq Computer Corporation. All rights reserved

Limitation of liability:  This publication and the software it describes are provided ``as is'' without warranty of any kind, express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

This publication could include technical inaccuracies or typographical errors.  Furthermore, the Compaq Extended Static Checker for Java (ESC/Java) is currently under development.  Compaq therefore expects that changes will occur in the ESC/Java software and documentation, from time to time.  Compaq reserves the right to adopt such changes, or to cause or recommend that ESC/Java users adopt such changes, upon such notice as is practicable under the circumstances or without any notice, in its discretion.

The Compaq Extended Static Checker for Java (ESC/Java) is not a product of Sun Microsystems, Inc.

Compaq is a registered trademark of Compaq Computer Corporation.  Java is a trademark or registered trademark of Sun Microsystems, Inc.  Any other trademarks or registered trademarks mentioned herein are the property of their respective holders.


Abstract

This document is intended to be a non-detailed, trimmed-down version of the ESC/Java User's Manual, for people who would like to get an overview of the annotation language supported by the Compaq Extended Static Checker for Java (ESC/Java) without getting immersed in all its technical intricacies.

For more detailed information, please refer to the ESC/Java User's Manual. For information about the invocation of the ESC/Java checker, please see the escjava(1) man page included with the ESC/Java download available from http://research.compaq.com/SRC/esc/.


0.  What does ESC/Java do anyway?

Type annotation and static type checking of programs have proved to be one of biggest engineering successes of computer science. Typing provides a coarse semantics for programs, since it pays no attention to the semantics of any language constructs that are not related to types. Nevertheless, the automatic type checking of programs weeds out already at compile time many of the most common programming errors, thus making them less costly for the developers. Also, typing forces a certain discipline upon the programmer, which results in better programs.

The Compaq Extended Static Checker for Java (ESC/Java) pushes the idea behind type checkers a few steps further. The class of errors that it looks for is much larger and more varied: it addresses, among others, the potential run-time errors that arise from illegal array operations, null-pointer dereferencing, deadlocks and race conditions of threads. Given a Java program, it automatically infers and checks a set of verification conditions that correspond to the described classes of errors.  It also allows the programmer to record design decisions, and to influence the choice of verification conditions by annotating the program with a set of pragmas. These can be used to specify the pre- and postconditions of routines, properties of abstract data types, invariants of loops, and much more.

The errors that ESC/Java looks for are chosen on a pragmatic basis; they are the errors that, according to the engineering experience, occur often and are relatively cheap to find, but the ESC/Java system is flexible and can be extended to allow for checking of other types of errors. Currently, ESC/Java checks almost the entire Java 1.2 language, including all of Java 1.0.

In terms of program verification, ESC/Java is unsound, because it can miss real programming errors (from the targeted class), and it is incomplete, because it can give some spurious warnings. Some degree of inaccuracy is inevitable in a tool such as ESC/Java due to theoretical limits of decidability.  Additionally, the design of ESC/Java intentionally sacrifices some accuracy in trade for efficiency of the tool.  The user has some control over ESC/Java's unsoundness and incompleteness thanks to pragmas. These pragmas not only enable modular program checking, but are also a convenient formalism for recording programmers' design decisions and program specifications.

The remainder of this page gives a rough description of the kinds of pragmas available in the current ESC/Java, the specification expressions that can occur in those pragmas, and the kinds of warnings ESC/Java reports..

1.  There are four syntactic categories of ESC/Java pragmas:

A pragma (annotation) is enlosed in a Java comment whose first character is an @. For example, /*@ non_null */ is an ESC/Java pragma. All pragmas enclosed in a single Java comment must be of the same syntactic category.

2.  The list of ESC/Java pragmas with their (syntactic, semantic) contexts:

For pragmas terminated by semicolon, the semicolon is optional if there are no further pragmas enclosed in the same comment.

3.  The ESC/Java specification expressions:

A specification type is either a Java type or one of the special types \TYPE or \LockSet (or an array of special types, for example \TYPE[][]). The specification type \LockSet cannot be mentioned explicitly in annotations.

Specification expressions must be free of subexpressions that may potentially have side effects, so they may not contain any assignment (=, +=, etc.), pre/post-increment/decrement (++ or --), array or object creation (new), or method invocation (even for methods that have no side-effects).

The additional constructs that are allowed in specification expressions beyond those allowed in Java expressions are:

4.  The ESC/Java modification targets (or specification designators):

5.  The ESC/Java warning types:

ESC/Java issues warnings for conditions that it regards as run-time errors, and that, so far is it can tell, might actually occur at run-time.