Part 1 - Programming in the Large

How were the legacy systems of the past built using only Java Classes and Packages?
In object-oriented programming, the basic unit of reuse is traditionally the class. Java has wonderful mechanisms for promoting reuse of a class:

1. inheritance for reusing behavior,
2. interfaces for reusing abstractions, separate compilation, dynamic linking and access control down to the level of individual fields and methods.

We had nested classes since 1997, so it should be possible for a single top-level class to encapsulate a vast amount of functionality.

With that in mind it seems that an application could be a single package containing a few very rich classes, all sharing data and fields accessible within the package and where a handful of public classes form the entry points or the API of the application. Right?

1. How many people work on a code base that consists of one package? Two packages just your own codebase not the dependencies?
2. How many people work on a code base that consists of three packages?
3. How many people work on a code base that is on the order of 10, 20 or 50 packages?

This has made my point far better than I could have made myself. Programs do not consist of a handful of packages anymore.
Even the smallest microservice would not be expected to fit into a single package.Programs are packages and not classes in Java.
Unfortunately the Java language kind of gives up once your program is bigger than a single package. Just imagine how difficult it is to control reuse within a really large code base. For example, JDK 8 has 217 official packages in it.
The only way to share code between packages is with the public modifier, but then you are sharing it with everyone. It is not surprising that packaged friendship in one form or another has been requested many times over the years. A package is a great way to organize classes, but most people wish there was a way to organize packages to.

The Java 9 module system has several advantages over the traditional package system:

1. Strong encapsulation: The module system provides stronger encapsulation than the package system by allowing modules to hide their internal implementation details by default.
2. Improved reliability and security: The module system allows for more reliable and secure code by making it more difficult for modules to accidentally or maliciously access code that they should not.
3. Improved performance: The module system can improve performance by allowing the Java Virtual Machine (JVM) to more efficiently load and resolve dependencies between modules.
4. Better organization and maintainability: The module system allows for better organization and maintainability of large code bases by providing a way to group related code together in a single module and to express explicit dependencies between modules.
5. Easier to identify and manage dependencies: The module system makes it easier to identify and manage dependencies between different parts of a codebase, reducing the risk of errors and inconsistencies.
6. Services: The module system allows for the use of services, which is a way to allow a module to make some of its functionality available to other modules.
7. Interoperability: The module system allows for better interoperability between different modules, making it easier to reuse code and to create modular applications.
8. Improved maintainability: The module system allows for easier maintenance of large code bases by providing a way to group related code together in a single module and to express explicit dependencies between modules.