Separation of Concerns

This principle is ultimately about separation of concerns, which means you reuse someone's code, not by copy pasting it into your own source tree, but by depending on the black box artifact released by someone else.
Now in the Java ecosystem there is no question that the unit of release is the "jar file". That does not change with modules, a jar file simply carries the module-info.class file produced from module-info.java, alongside the ordinary class files.
This is known as a modular jar.
When someone releases a modular jar for the "hello.world module", it is reused by someone else, writing requires hello world in their own module-info.java.
The reuser benefits from an explicit coherent API consisting of precisely the green exported packages and the releaser benefits from strong encapsulation of concealed packages inside the module which support the exported API.

Creating programs that can handle very complex tasks calls for separation of concerns, allowing concentration on different parts of the design in isolation. At the same time, the intricate interactions within the system must be maintained in spite of the separation.
Distributed system architectures, such as J2EE and CORBA, provide special publishing mechanisms for SERVICES, with conventions for their use, and they add distribution and access capabilities. But such frameworks are not always in use on a project, and even when they are, they are likely to be overkill when the motivation is just a logical separation of concerns.

Separation of concerns (SoC) is a design principle that states that a software program should be separated into distinct sections, such that each section addresses a separate concern. The main characteristics of SoC are:

1. Modularity: Each concern is handled by a separate module or component, making it easy to understand, modify, and test the software.
2. Loose coupling: The different modules or components are not tightly dependent on each other, making it possible to change or replace one component without affecting the others.
3. High cohesion: Each module or component has a clear and specific responsibility, making the software easy to understand and maintain.
4. Reusability: Modules or components can be reused in other parts of the software or in other software projects, reducing development time and increasing reliability.
5. Abstraction: SoC makes it possible to abstract away low-level implementation details, making it easier to understand and reason about the software.