BRICS · Contents · Programme

Applications of Type Constraints in Software Engineering Tools

A BRICS Mini-Course
June 14, 2004

Lectures by
Frank Tip, tip@watson.ibm.com
IBM T.J. Watson Research Center


Course Contents

Type constraints were introduced in the early 90s as a mechanism for checking that certain kinds of run-time errors (e.g., "message not understood" errors) cannot arise during the execution of an object-oriented program. In this previous work, a set of type constraints is generated from a program using a set of syntax-driven rules that are matched against the program's expressions, and the desired safety property is proven by showing that a solution exists to the resulting system of constraints.

In our research, we use similar systems of type constraints to support several kinds of semantics-preserving program transformations that aim at improving a program's design or performance characteristics. Specifically, we use type constraints for:

1) checking the preconditions and allowable source code modifications for refactorings related to generalization such as "Extract Interface" and "Generalize Type", 2) determining where custom versions of standard Java container classes such as "Vector" and "Hashtable" can be used in a client application in order to improve performance, 3) converting Java applications that use standard container classes such as "HashMap" or "ArrayList" to use the parameterized counterparts of these containers that will be part of JDK 1.5's generic standard collection libraries, and 4) migration Java applications that use deprecated/legacy types such as Vector, Hashtable, and Enumeration to new container types such as ArrayList, HashMap, and Iterator that provide roughly the same functionality.

In each of these applications, a set of type constraints is derived from the original program, and an analysis of the constraint system is used to determine where program transformations are allowed without effecting type correctness or program behavior. Several of these program transformations have been implemented as refactorings in the Eclipse development environment (www.eclipse.org), and will be demonstrated during the presentation.

Note: This presentation is based on several joint research activities with Dirk Baeumer (IBM Zurich), Ittai Balaban (NYU), Bjorn De Sutter (Ghent University), Julian Dolby (IBM T.J. Watson), Robert Fuhrer (IBM T.J. Watson), and Adam Kiezun (MIT). Parts of this work can be found in papers presented at OOPSLA'03 and ECOOP'04.

Programme

Monday June 14, 2004, 13:15-15:00 in Turing 016