Modular Program Structure

So here is the same application developed as modules. Let us turn the API.jar into a modular jar by adding a module declaration.
The module called API exports the package P to everyone. That is the main API and exports the helper package P.Helper to its friend modules Impl1 and Impl2.

The second export directive of P.exports is called a qualified exports. Any module in the world can require the API module and access the package P, but only the friend Modules can access the package P.Helper. I am not showing the module declarations for the friend modules, but they will obviously require the API module in order to access the P.Foo interface that they implement.

The friend modules will not export anything and they can organize their concealed packages as they wish. Now the P.Helper package isn't overloaded with implementation classes multiple jars.
The naming of packages is much clearer throughout all three jars and more implementations can be added smoothly. In effect, Modules make packages as cheap as classes and then control the reuse of packages very precisely.

1. A module is a set of packages designed for reuse.
2. Modules offer strong encapsulation and reliable dependencies and
3. the Module-aware tooling (the command-line tool in IDEs) will be a big parts of modular developments.