Empowering Collections with Swarm Behavior

Often, when modelling a system there are properties and operations that are related to a group of objects rather than to a single object. In this paper we extend Java with Swarm Behavior, a new composition operator that associates behavior with a collection of instances. The lookup resolution of swarm behavior is based on the element type of a collection and is thus orthogonal to the collection hierarchy

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

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

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

The Java 5 Generics Compromise Orthogonality to Keep Compatibility

In response to a long-lasting anticipation by the Java community, version 1.5 of the Java 2 platform - referred to as Java 5 - introduced generic types and methods to the Java language. The Java 5 generics are a significant enhancement to the language expressivity because they allow straightforward composition of new generic classes from existing ones while reducing the need for a plethora of type casts. While the Java 5 generics are expressive, the chosen implementation method, type erasure, has triggered undesirable orthogonality violations. This paper identifies six cases of orthogonality violations in the Java 5 generics and demonstrates how these violations are mandated by the use of type erasure. The paper also compares the Java 5 cases of orthogonality violations to compatible cases in C# 2 and NextGen 2 and analyzes the trade-offs in the three approaches. The conclusion is that Java 5 users face new challenges: a number of generic type expressions are forbidden, while others that are allowed are left unchecked

C# 3.0 makes OCL redundant!

Other than its 'platform independence' the major advantages of OCL over traditional Object Oriented programming languages has been the declarative nature of the language, its powerful navigation facility via the iteration operations, and the availability of tuples as a first class concept. The recent offering from Microsoft of the "Orcas" version of Visual Studio with C# 3.0 and the Linq library provides functionality almost identical to that of OCL. This paper examines and evaluates the controversial thesis that, as a result of C# 3.0, OCL is essentially redundant, having been superseded by the incorporation of its advantageous features into a mainstream programming language

STATIC TYPE CHECKER TOOLS FOR DART

This project presents the static type checkers that I developed for the optional type system of the Dart programming language. Dart is an optionally typed language and as a result has an unsound type system. In this project I have created the static type checker tools for dart. The first static type checker tool ensures mandatory typing of Dart code. This checker can be invoked by giving a new compiler option that I have added to the compiler configuration. This checker will help in catching any type errors early at compile time rather than at run time. The second static type checker improves the Dart’s support for covariant generics. This static checker issues warnings at compile time if the covariant use of generics is followed by a modification of the collection passed covariantly. I have also introduced three annotations that will add more type safety to the Dart programming language. The @notnull annotation is to ensure that null values are not passed as arguments to method parameters. This nullness checker ensures that a running program will never throw a null pointer exception. The @modifies annotation supports the covariance check. The @linear annotation is used to prevent unexpected modification of objects by aliasing. The @linear annotation can be used in conjunction with Dart isolates for concurrent programming

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