On Modularity, Modules, and Java

Foreword to The Java Module System by Nicolai Parlog

The motivation and desire for modularity is not new. In the proceedings of the 1968 NATO Software Engineering conference, the landmark conference that helped popularize the term software engineering and a vision of software components, E E David outlines an approach for the development of large systems:

Define a subset of the system which is small enough to be manageable, then build on that subsystem. This strategy requires that the system be designed in modules which can be realized, tested, and modified independently, apart from conventions for intermodule communication.

From the same conference, H R Gillette describes how modularity supports a system’s evolution:

Modularity helps to isolate functional elements of the system. One module may be debugged, improved, or extended with minimal personnel interaction or system discontinuity.

Nothing new, then. It just took languages and practices a while to catch on and explore variations on these themes. What is new is how Java 9 onward embraces modularity.

The story of Java modularity is scattered like pieces of a jigsaw puzzle across time and space, carefully coded into history.

Java’s first and most fundamental realization of a module was the class. In other languages a class represents a unification of modularity and a type, affording a type, its operations, and its details some privacy and cohesion. Java took this one step further, projecting the class from source artifact into binary component.

In answering the question “How small is small enough to be manageable?” the class turns out to be too small. As Marx and Engels observed in 1848:

The history of all hitherto existing society is the history of class struggles.

For any but the smallest of codebases or most debt-ridden of classes, the class is not the large-scale component architecture you were looking for.

Java also arrived with the false promise of the package, a word with all the right connotations — something that is sealed and sent, a coherent and wrapped indivisible whole ready to go — but none of the follow-through — namespaces for organizing code into folders, open plan rather than compartmentalized, more indiscreet than discrete, labeled and weighed down by trendy-at-the-time but ultimately impractical domain names.

And then came Pandora’s moment, a myth made manifest. The Greek myth of Pandora, the girl with all the gifts, is typically mistold: she is described as opening a box that releases ills on all of humanity. It wasn’t a box: it was a jar. What she opened was a pithos, a jar, but this got mistranslated to pyxis, a box. Just as in code, names matter.

JARs were a foot in the door of a component model, but the door had not been opened much beyond zipping class files together. To combat JAR hell, many approaches — perhaps most visibly build tools and OSGi bundles — extended the JAR model and its manifest to take us further along the road of modularity.

But all that’s past. What now? What of the future?

The answer is in front of you. That’s why you’re reading this book.

Java 9 brought many of the pieces of the jigsaw puzzle together in its modules, a system woven into the core of the platform rather than as an extension beyond it.

Java’s module system has to negotiate the past. It has to retain the investment in a wealth of existing code, to not mess with an existing ecosystem, yet at the same time offer something that makes sense for code yet to be written in an ever-changing world.

At the mechanical level, you need to understand the nature of a module, the nature of dependencies, the details of syntax and componentization. From a design perspective you need to know the good, the bad, and the ugly of working with modules. As with any construct or concept, modularity is not a magic sauce you simply add to your development; it requires care, skill, and attention. You need answers to the question of what happens to your existing code in a more modular world, to the question of how will it affect your deployment, your development, and to the questions you have yet to discover you need answers to.

That’s a lot of questions. That’s why you’re reading this book.

Nicolai is here to answer these questions and more. He has tracked modules since they appeared on the radar. He has dived into depths and swum the shallows of JSRs and implementations. He has gone into details you don’t want to so that you don’t have to. His care and attention to the detail and the practice allows you to care and make good on his distillation of knowledge — from theory to practice, from entry level to advanced.

This is the book with all the gifts. Open, read, enjoy.