front matter
foreword
The motivation and desire for modularity isn’t 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 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. 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. 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.