Nicolai Parlog - The Java Module System

Nicolai Parlog

Foreword by Kevlin Henney

Manning

Shelter Island

The motivation and desire for modularity isnt new. In the proceedings of the 1968 NATO Software Engineering Conference, the landmark conference that played a major role in popularizing a vision of software components and the term software engineering, E. E. David outlined 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.

At the same conference, H. R. Gillette described how modularity supported a systems 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. It just took languages and practices a while to catch on and explore variations on these themes.

The story of Java modularity is scattered like pieces of a jigsaw puzzle across time and space, carefully coded into history. Javas 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.

Alas, 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.

The Communist Manifesto

For any but the smallest of code bases 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 connotationssomething that is sealed and sent, a coherent and wrapped indivisible whole ready to gobut 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 Pandoras 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 wasnt a box: it was a jar. What she opened was a pithos, a jar, but this was mistranslated to pyxis, a box. Just as in code, names matter.

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

But all thats past. What now? What of the future?

The answer is in front of you. Thats why youre 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 an extension beyond it. Javas 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, and 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 it will affect your deployment and your development, and to the questions you have yet to discover you need answers to.

Thats a lot of questions. Thats why youre 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 the depths and swum the shallows of JSRs and implementations. He has gone into details you dont want to, so you dont have to. His care and attention to detail allow you to make good on his distillation of knowledgefrom theory to practice, from entry level to advanced.

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

Kevlin Henney, Curbralan