A compiler-checked immutability guarantee provides useful documentation, facilitates reasoning, and enables optimizations. This paper presents Immutability Generic Java (IGJ), a novel language extension that expresses immutability without changing Java’s syntax by building upon Java’s generics and annotation mechanisms. In IGJ, each class has one additional type parameter that is Mutable, Immutable, or ReadOnly. IGJ guarantees both reference immutability (only mutable references can mutate an object) and object immutability (an immutable reference points to an immutable object). IGJ is the first proposal for enforcing object immutability within Java’s syntax and type system, and its reference immutability is more expressive than previous work. IGJ also permits covariant changes of type parameters in a type-safe manner, e.g., a readonly list of integers is a subtype of a readonly list of numbers. IGJ extends Java’s type system with a few simple rules. We formalize this type system and prove it sound. Our IGJ compiler works by typeerasure and generates byte-code that can be executed on any JVM without runtime penalty.

SafeGen is a meta-programming language for writing statically safe generators of Java programs. If a program generator written in SafeGen passes the checks of the SafeGen compiler, then the generator will only generate well-formed Java programs, for any generator input. In other words, statically checking the generator guarantees the correctness of any generated program, with respect to static checks commonly performed by a conventional compiler (including type safety, existence of a superclass, etc.). To achieve this guarantee, SafeGen supports only language primitives for reflection over an existing well-formed Java program, primitives for creating program fragments, and a restricted set of constructs for iteration, conditional actions, and name generation. SafeGen’s static checking algorithm is a combination of traditional type checking for Java, and a series of calls to a theorem prover to check the validity of first-order logical sentences constructed to represent well-formedness properties of the generated program under all inputs. The approach has worked quite well in our tests, providing proofs for correct generators or pointing out interesting bugs.

Software-product-line engineering is an efficient means to generate a family of program variants for a domain from a single code base. However, because of the potentially high number of possible program variants, it is difficult to test them all and ensure properties like type safety for the entire product line. We present a product-line–aware type system that can type check an entire software product line without generating each variant in isolation. Specifically, we extend the Featherweight Java calculus with feature annotations for product-line development and prove formally that all program variants generated from a well-typed product line are well-typed. Furthermore, we present a solution to the problem of typing mutually exclusive features. We discuss how results from our formalization helped implementing our own product-line tool CIDE for full Java and report of experience with detecting type errors in four existing software-product-line implementations.

Abstract. We present MJ: a language for specifying general classes whose members are produced by iterating over members of other classes. We call this technique “class morphing ” or just “morphing”. Morphing extends the notion of genericity so that not only types of methods and fields, but also the structure of a class can vary according to type variables. This offers the ability to express common programming patterns in a highly generic way that is otherwise not supported by conventional techniques. For instance, morphing lets us write generic proxies (i.e., classes that can be parameterized with another class and export the same public methods as that class); default implementations (e.g., a generic do-nothing type, configurable for any interface); semantic extensions (e.g., specialized behavior for methods that declare a certain annotation); and more. MJ’s hallmark feature is that, despite its emphasis on generality, it allows modular type checking: an MJ class can be checked independently of its uses. Thus, the possibility of supplying a type parameter that will lead to invalid code is detected early—an invaluable feature for highly general components that will be statically instantiated by other programmers. 1

We present MorphJ: a language for specifying general classes whose members are produced by iterating over members of other classes. We call this technique “class morphing ” or just “morphing”. Morphing extends the notion of genericity so that not only types of methods and fields, but also the structure of a class can vary according to type variables. This adds a disciplined form of meta-programming to mainstream languages and allows expressing common programming patterns in a highly generic way that is otherwise not supported by conventional techniques. For instance, morphing lets us write generic proxies (i.e., classes that can be parameterized with another class and export the same public methods as that class); default implementations (e.g., a generic do-nothing type, configurable for any interface); semantic extensions (e.g., specialized behavior for methods that declare a certain annotation); and more. MorphJ’s hallmark feature is that, despite its emphasis on generality, it allows modular type checking: a MorphJ class can be checked independently of its uses. Thus, the possibility of supplying a type parameter that will lead to invalid code is detected early—an invaluable feature for highly general components that will be statically instantiated by other programmers. We demonstrate the benefits of morphing with several examples, including a MorphJ reimplementation of DSTM2, a software transactional memory library, which reduces 1,484 lines of Java reflection and bytecode engineering library calls to just 586 lines of MorphJ code.

The C preprocessor is commonly used to implement variability. Given a feature selection, code fragments can be excluded from compilation with #ifdef and similar directives. However, the token-based nature of the C preprocessor makes variability implementation difficult and error-prone. Additionally, variability mechanisms are intertwined with macro definitions, macro expansion, and file inclusion. To determine whether a code fragment is compiled, the entire file must be preprocessed. We present a partial preprocessor that preprocesses file inclusion and macro expansion, but retains variability information for further analysis. We describe the mechanisms of the partial preprocessor, provide a full implementation, and present some initial experimental results. The partial preprocessor is part of a larger endeavor in the TypeChef project to check variability implementations (syntactic correctness, type correctness) in C projects such as the Linux kernel. 1.

This technical report contains proofs that were omitted from our paper entitled “Ownership and Immutability in Generic Java”. Please read the paper first, and only then proceed to reading this technical report, because this technical report is not self contained. We only include a summary of the syntax (Fig. 1), subtyping rules (Fig. 2), expression typing rules (Fig. 3), and reduction rules (Fig. 4).

Variance allows the safe integration of parametric and subtype polymorphism. Two flavors of variance, definition-site versus usesite variance, have been studied and have had their merits hotly debated. Definition-site variance (as in Scala and C#) offers simple type-instantiation rules, but causes fractured definitions of naturally invariant classes; Use-site variance (as in Java) offers simplicity in class definitions, yet complex type-instantiation rules that elude most programmers. We present a unifying framework for reasoning about variance. Our framework is quite simple and entirely denotational, that is, it evokes directly the definition of variance with a small core calculus that does not depend on specific type systems. This general framework can have multiple applications to combine the best of both worlds: for instance, it can be used to add use-site variance annotations to the Scala type system. We show one such application in detail: we extend the Java type system with a mechanism that modularly infers the definition-site variance of type parameters, while allowing use-site variance annotations on any type-instantiation. Applying our technique to six Java generic libraries (including the Java core library) shows that 20-58 % (depending on the library) of generic definitions are inferred to have single-variance; 8-63 % of method signatures can be relaxed through this inference, and up to 91 % of existing wildcard annotations are unnecessary and can be elided.

Abstract not found

The JAVA language has no support for the important notions of ownership (an object owns its representation to prevent unwanted aliasing or modifications) and immutability (the division into mutable, immutable, and readonly data and references). Programmers are prone to design errors such as representation exposure or violation of immutability contracts. This paper presents Ownership Immutability Generic Java (OIGJ), a backward-compatible purely-static language extension supporting ownership and immutability. We formally defined the OIGJ typing rules and proved them sound. We also implemented OIGJ and performed case studies of 33,000 lines of code. OIGJ is the first type system to unify the two main variants of ownership: owner-as-dominator, which restricts aliasing, and owner-as-modifier, which restricts modifications. Thus, the programmer has the flexibility to choose whether the representation of an object cannot leak (the object dominates the representation) or whether it may be freely shared as readonly (but only the owning object can modify it). OIGJ is easy for a programmer to use, and it is easy to implement (flow insensitive, using only 15 rules). Yet, OIGJ is more expressive than previous ownership languages, because it can type-check more good code. OIGJ can express the factory and visitor patterns, and OIGJ can type-check Sun’s java.util collections (excluding the clone method) without refactoring and with only a small number of annotations. Previous work required major refactoring of existing code in order to fit its ownership restrictions. Forcing refactoring of well-designed code is undesirable because it costs programmer effort, results in worse design, and hinders adoption in the mainstream community. [Copyright notice will appear here once ’preprint ’ option is removed.]