Safer typing of complex API usage through Java generics

When several incompatible implementations of a single API are in use in a Java program, the danger exists that instances from different implementations may inadvertently be mixed, leading to errors. In this paper we show how to use generics to prevent such mixing. The core idea of the approach is to add a type parameter to the interfaces of the API, and tie the classes that make up an implementation to a unique choice of type parameter. In this way methods of the API can only be invoked with arguments that belong to the same implementation. We show that the presence of a type parameter in the interfaces does not violate the principle of interface-based programming: clients can still completely abstract over the choice of implementation. In addition, we demonstrate how code can be reused between different implementations, how implementations can be defined as extensions of other implementations, and how different implementations may be mixed in a controlled and safe manner. To explore the feasibility of the approach, gauge its usability, and identify any issues that may crop up in practical usage, we have refactored a fairly large existing API-based application suite, and we report on the experience gained in the process

Extending the Java language for the prevention of data races

Thesis (M.Eng.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2002.Includes bibliographical references (p. 81-82).This electronic version was submitted by the student author. The certified thesis is available in the Institute Archives and Special Collections.This thesis presents a language extension for Java that ensures that type-checked programs will be free of race conditions. By adding parameterization to class types, this mostly static type-system allows programmers to write generic object code independent of the concurrency protection mechanism to be used to guard it. This added flexibility makes this extension more expressive and easier to use than other similar type systems. We will present the formal type system as well as our experience with implementing a compiler for this extension.by Robert Honway Lee.M.Eng

Towards a Java Subtyping Operad

The subtyping relation in Java exhibits self-similarity. The self-similarity in Java subtyping is interesting and intricate due to the existence of wildcard types and, accordingly, the existence of three subtyping rules for generic types: covariant subtyping, contravariant subtyping and invariant subtyping. Supporting bounded type variables also adds to the complexity of the subtyping relation in Java and in other generic nominally-typed OO languages such as C# and Scala. In this paper we explore defining an operad to model the construction of the subtyping relation in Java and in similar generic nominally-typed OO programming languages. Operads, from category theory, are frequently used to model self-similar phenomena. The Java subtyping operad, we hope, will shed more light on understanding the type systems of generic nominally-typed OO languages.Comment: 13 page

Refactoring for parameterizing Java classes

Type safety and expressiveness of many existing Java libraries and theirclient applications would improve, if the libraries were upgraded to definegeneric classes. Efficient and accurate tools exist to assist clientapplications to use generics libraries, but so far the libraries themselvesmust be parameterized manually, which is a tedious, time-consuming, anderror-prone task. We present a type-constraint-based algorithm forconverting non-generic libraries to add type parameters. The algorithmhandles the full Java language and preserves backward compatibility, thusmaking it safe for existing clients. Among other features, it is capableof inferring wildcard types and introducing type parameters formutually-dependent classes. We have implemented the algorithm as a fullyautomatic refactoring in Eclipse.We evaluated our work in two ways. First, our tool parameterized code thatwas lacking type parameters. We contacted the developers of several ofthese applications, and in all cases where we received a response, theyconfirmed that the resulting parameterizations were correct and useful.Second, to better quantify its effectiveness, our tool parameterizedclasses from already-generic libraries, and we compared the results tothose that were created by the libraries' authors. Our tool performed therefactoring accurately -- in 87% of cases the results were as good as thosecreated manually by a human expert, in 9% of cases the tool results werebetter, and in 4% of cases the tool results were worse

Generic Model Refactorings

Many modeling languages share some common concepts and principles. For example, Java, MOF, and UML share some aspects of the concepts\ud of classes, methods, attributes, and inheritance. However, model\ud transformations such as refactorings specified for a given language\ud cannot be readily reused for another language because their related\ud metamodels may be structurally different. Our aim is to enable a\ud flexible reuse of model transformations across various metamodels.\ud Thus, in this paper, we present an approach allowing the specification\ud of generic model transformations, in particular refactorings, so\ud that they can be applied to different metamodels. Our approach relies\ud on two mechanisms: (1) an adaptation based mainly on the weaving\ud of aspects; (2) the notion of model typing, an extension of object\ud typing in the model-oriented context. We validated our approach by\ud performing some experiments that consisted of specifying three well\ud known refactorings (Encapsulate Field, Move Method, and Pull Up Method)\ud and applying each of them onto three different metamodels (Java,\ud MOF, and UML)

Adjunctions for exceptions

An algebraic method is used to study the semantics of exceptions in computer languages. The exceptions form a computational effect, in the sense that there is an apparent mismatch between the syntax of exceptions and their intended semantics. We solve this apparent contradiction by efining a logic for exceptions with a proof system which is close to their syntax and where their intended semantics can be seen as a model. This requires a robust framework for logics and their morphisms, which is provided by categorical tools relying on adjunctions, fractions and limit sketches.Comment: In this Version 2, minor improvements are made to Version