Taming wildcards in Java's type system

Abstract

Wildcards have become an important part of Java's type system since their introduction 7 years ago. Yet there are still many open problems with Java's wildcards. For example, there are no known sound and complete algorithms for subtyping (and consequently type checking) Java wildcards, and in fact subtyping is suspected to be undecidable because wildcards are a form of bounded existential types. Furthermore, some Java types with wildcards have no joins, making inference of type arguments for generic methods particularly difficult. Although there has been progress on these fronts, we have identified significant shortcomings of the current state of the art, along with new problems that have not been addressed.In this paper, we illustrate how these shortcomings reflect the subtle complexity of the problem domain, and then present major improvements to the current algorithms for wildcards by making slight restrictions on the usage of wildcards. Our survey of existing Java programs suggests that realistic code should already satisfy our restrictions without any modifications. We present a simple algorithm for subtyping which is both sound and complete with our restrictions, an algorithm for lazily joining types with wildcards which addresses some of the shortcomings of prior work, and techniques for improving the Java type system as a whole. Lastly, we describe various extensions to wildcards that would be compatible with our algorithms.

Getting F-bounded polymorphism into shape

“…However, here we will be using use-site variance, a simplification of Java wildcards [6]. Tate discusses the relationships between these systems [19], but for this paper one need only understand that use-site variance is more expressive than declaration-site variance and discards the implicit constraints of wildcards, since the complications of implicit constraints far outweigh their usefulness [20].…”

“…In Section 6, we will discuss additional existing challenges and new features we hope to address in future work by extending the techniques we present here. [11,20], and consequently we can use it to cause javac to stack overflow. ‡ When we refer to javac we mean the OpenJDK 1.7.0 25 type checker.…”

“…proposed an alternative restriction that guarantees decidability for wildcards and uses a more efficient algorithm [20], but their restriction is less accommodating of contravariance. Regardless of which one might be better, both solutions grew from algorithmic perspectives, recognizing current practice only insofar as to show backwards compatibility with existing code.…”

“…It uses expansive inheritance by having List<E> use List<Equatable<E>> in its inherited type, thereby violating Kennedy and Pierce's requirement [11]. It also uses nested contravariance, with Equatable being used at a noncovariant position in the inherited type, thereby violating Tate et al's requirement [20]. Yet this design is being rejected for reasons that industry developers would view as purely academic.…”

“…Using Material-Shape Separation, we were able to develop a simple sound and complete subtyping algorithm, one capable of incorporating type equivalence even in invariant types, a problem raised by Tate et al [20] and not well addressed by any of the existing proposals for restricting generics. More importantly, we developed a sound and complete algorithm for computing the join of two types, a problem raised by Smith and Cartwright [18] and also not well addressed by any of the existing proposals.…”