The C++0x "Concepts" Effort

C++0x is the working title for the revision of the ISO standard of the C++ programming language that was originally planned for release in 2009 but that was delayed to 2011. The largest language extension in C++0x was "concepts", that is, a collection of features for constraining template parameters. In September of 2008, the C++ standards committee voted the concepts extension into C++0x, but then in July of 2009, the committee voted the concepts extension back out of C++0x. This article is my account of the technical challenges and debates within the "concepts" effort in the years 2003 to 2009. To provide some background, the article also describes the design space for constrained parametric polymorphism, or what is colloquially know as constrained generics. While this article is meant to be generally accessible, the writing is aimed toward readers with background in functional programming and programming language theory. This article grew out of a lecture at the Spring School on Generic and Indexed Programming at the University of Oxford, March 2010

OpenJML: Software verification for Java 7 using JML, OpenJDK, and Eclipse

OpenJML is a tool for checking code and specifications of Java programs. We describe our experience building the tool on the foundation of JML, OpenJDK and Eclipse, as well as on many advances in specification-based software verification. The implementation demonstrates the value of integrating specification tools directly in the software development IDE and in automating as many tasks as possible. The tool, though still in progress, has now been used for several college-level courses on software specification and verification and for small-scale studies on existing Java programs.Comment: In Proceedings F-IDE 2014, arXiv:1404.578

Proactive Empirical Assessment of New Language Feature Adoption via Automated Refactoring: The Case of Java 8 Default Methods

Programming languages and platforms improve over time, sometimes resulting in new language features that offer many benefits. However, despite these benefits, developers may not always be willing to adopt them in their projects for various reasons. In this paper, we describe an empirical study where we assess the adoption of a particular new language feature. Studying how developers use (or do not use) new language features is important in programming language research and engineering because it gives designers insight into the usability of the language to create meaning programs in that language. This knowledge, in turn, can drive future innovations in the area. Here, we explore Java 8 default methods, which allow interfaces to contain (instance) method implementations. Default methods can ease interface evolution, make certain ubiquitous design patterns redundant, and improve both modularity and maintainability. A focus of this work is to discover, through a scientific approach and a novel technique, situations where developers found these constructs useful and where they did not, and the reasons for each. Although several studies center around assessing new language features, to the best of our knowledge, this kind of construct has not been previously considered. Despite their benefits, we found that developers did not adopt default methods in all situations. Our study consisted of submitting pull requests introducing the language feature to 19 real-world, open source Java projects without altering original program semantics. This novel assessment technique is proactive in that the adoption was driven by an automatic refactoring approach rather than waiting for developers to discover and integrate the feature themselves. In this way, we set forth best practices and patterns of using the language feature effectively earlier rather than later and are able to possibly guide (near) future language evolution. We foresee this technique to be useful in assessing other new language features, design patterns, and other programming idioms

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

Object and Reference Immutability using Java Generics

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 Javas syntax by building upon Javas generics and annotation mechanisms. In IGJ, each class has one additional generic parameter that is Immutable, Mutable, 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, and its reference immutability is more expressive than previous work. IGJ also permits covariant changes of generic arguments in a type-safe manner, e.g., a readonly list of integers is a subtype of a readonly list of numbers. IGJ extends Javas type system with a few simple rules. We formalize this type system and prove it sound. Our IGJ compiler works by type-erasure and generates byte-code that can be executed on any JVM without runtime penalty

Fast and Lean Immutable Multi-Maps on the JVM based on Heterogeneous Hash-Array Mapped Tries

An immutable multi-map is a many-to-many thread-friendly map data structure with expected fast insert and lookup operations. This data structure is used for applications processing graphs or many-to-many relations as applied in static analysis of object-oriented systems. When processing such big data sets the memory overhead of the data structure encoding itself is a memory usage bottleneck. Motivated by reuse and type-safety, libraries for Java, Scala and Clojure typically implement immutable multi-maps by nesting sets as the values with the keys of a trie map. Like this, based on our measurements the expected byte overhead for a sparse multi-map per stored entry adds up to around 65B, which renders it unfeasible to compute with effectively on the JVM. In this paper we propose a general framework for Hash-Array Mapped Tries on the JVM which can store type-heterogeneous keys and values: a Heterogeneous Hash-Array Mapped Trie (HHAMT). Among other applications, this allows for a highly efficient multi-map encoding by (a) not reserving space for empty value sets and (b) inlining the values of singleton sets while maintaining a (c) type-safe API. We detail the necessary encoding and optimizations to mitigate the overhead of storing and retrieving heterogeneous data in a hash-trie. Furthermore, we evaluate HHAMT specifically for the application to multi-maps, comparing them to state-of-the-art encodings of multi-maps in Java, Scala and Clojure. We isolate key differences using microbenchmarks and validate the resulting conclusions on a real world case in static analysis. The new encoding brings the per key-value storage overhead down to 30B: a 2x improvement. With additional inlining of primitive values it reaches a 4x improvement

Polymorphism - prose of Java programmers

In Java programming language as implemented in JDK 5.0 there appear rather advanced kinds of polymorphism, even if they are hidden under different names. The notion of polymorphism unifies many concepts present in typed programming languages, not necessary object-oriented. We briefly define some varieties of polymorphism and trace them in Java. Java shows that industrial programming languages are able to express more abstract patterns using rather involved theoretical means, hence the working programmer has to be better educated in order to understand them, recognize them in different programming languages under different names and superficial syntax, and make good use of them

Formal Language Recognition with the Java Type Checker

This paper is a theoretical study of a practical problem: the automatic generation of Java Fluent APIs from their specification. We explain why the problem\u27s core lies with the expressive power of Java generics. Our main result is that automatic generation is possible whenever the specification is an instance of the set of deterministic context-free languages, a set which contains most "practical" languages. Other contributions include a collection of techniques and idioms of the limited meta-programming possible with Java generics, and an empirical measurement demonstrating that the runtime of the "javac" compiler of Java may be exponential in the program\u27s length, even for programs composed of a handful of lines and which do not rely on overly complex use of generics

JavaFX as a Domain-Specific Language in Scala / Groovy

Domain-Specific Languages (DSLs) are optimized for developing applications in a particular domain. JavaFX is such a DSL for creating rich graphical user interfaces.One method to create a DSL is to implement it in an existing language. This offers the advantage that existing users of the language do not need to learn a new language to work in the DSL. Scala and Groovy are two upcoming Java based languages which boast a feature set that can be used to extend existing languages and facilitate DSL creation. In this project my goal was to evaluate the ability of Scala and Groovy to be DSL hosts. To this end, I implemented my own JavaFX like DSLs in Scala and Groovy and assessed their capability for constructing a DSL