A Modularity Bug in Java 8

TL;DR

This paper identifies a modularity bug in Java 8's interface system, demonstrated through a vector space design example, highlighting the need for language extension to fix the compilation error.

Contribution

It uncovers a specific modularity bug in Java 8's interface system using a practical example from teaching modular design.

Findings

The bug causes a compilation error in Java 8.

The bug affects modular object-oriented design.

A language extension is proposed to fix the bug.

Abstract

We demonstrate a modularity bug in the interface system of Java 8 on the practical example of a textbook design of a modular interface for vector spaces. Our example originates in our teaching of modular object-oriented design in Java 8 to undergraduate students, simply following standard programming practices and mathematical definitions. The bug shows up as a compilation error and should be fixed with a language extension due to the importance of best practices (design fidelity).

Full text

Keywords: component-based software construction, interface specifications, object-oriented programming, programming-language pragmatics

1 Introduction

We demonstrate a modularity bug in the interface system of Java 8 [Java8] on the practical example of a textbook design of a modular interface for vector spaces, which are very important for many computer applications of linear algebra. Our design is textbook in the sense that we simply follow standard programming practices and mathematical definitions, as any mathematically-inclined teacher of object-oriented programming in Java would do. That is, we construct our design from its standard algebraic components, thus ending up with not only a but actually the natural modular design (by the algebraic definition of vector spaces), which however—and to our great surprise and embarrassment to our students—fails compilation due to an important expressiveness limitation of the Java 8 language. This limitation resides in its (not so) generic type system and should be remedied with an appropriate language extension, for the sake of keeping best practices best and saving our faces to our students of Java.

Nota bene

We do not claim that it be impossible to model vector spaces in Java 8; it is possible. What we do claim is that it is impossible to specify with interfaces and implement with corresponding classes such spaces in Java 8 in the natural modular way, whereby we mean reflecting their algebraic structure with its definitional components (design fidelity). So the great modularity promise of component-based software construction with object-oriented programming in Java has not been fulfilled yet, even after more than 20 years. In particular (counterexample), it cannot be fulfilled in Java 8 when combining such basic components as a field of scalars (e.g., rational numbers) and an additive group of vectors of such scalars so as to form a vector space (e.g., over rationals). Unfortunately, not even the planned Java 9 module system [Java9Modularity]

• •

representing “a fundamental shift to modularity as a first-class citizen for the whole Java platform” and

• •

in which “interfaces play a central role”

offers the required basic modularity, perhaps because of prioritising packages (coarser-grained modularity through import and export control) over interfaces (finer-grained modularity through multiple-inheritance-based composition).

2 The bug

We demonstrate the modularity bug in the interface system of Java 8 by constructing our interface (specification) for vector spaces bottom-up from its standard algebraic (interface) components, combining them through multiple inheritance when needed. Luckily, Java 8 offers multiple inheritance from interfaces. Recall that from classes, Java 8 only offers single inheritance. Our following interface components specify the algebraic operations up to our sought vector spaces, however without stipulating their corresponding algebraic (equational) laws (constraints). It would be nice if also this could become possible in a future release of Java in which interfaces could carry such algebraic structure, à la algebraic specifications [AlgebraicSpecifications]. In particular, the commutativity of commutative rings is left implicit (unspecified) in the following corresponding interface (Page LABEL:page:CR).

Our interfaces are presented as divided up into non-problematic and problematic components. The non-problematic interface components are meant to illustrate important modular (algebraic) interface specifications that are possible in Java 8 (though unfortunately still without algebraic constraints). The problematic interface components are meant to demonstrate an important modular (algebraic) interface specification that is not possible in Java 8, namely the one for vector spaces (our bug). The frontier between the non-problematic and the problematic is our empirical evidence for our claimed expressiveness limitation in Java 8 and motivates our suggested language extension therefor.

2.1 Non-problematic interfaces

Our first (atomic) interface component for vector spaces is the following one for (commutative) additive semigroups. These carry one binary operation, here called plus, specified with an explicit parameter right, with the corresponding parameter left left implicit, as is typical in object-oriented programming languages. (We can refer to this implicit parameter with the Java-keyword this.)

algebra.AdditiveSemigroup