Post History

If you are planning to share the application with individual users (rather than deploying it to a server), declaring your module dependencies explicitly allows [jlink](https://docs.oracle.com/en/java/javase/20/docs/specs/man/jlink.html) to create a stripped-down Java runtime in the application image (and thus in the user’s installation).

Aside from that, using modules is like using the `private` keyword, but at the package level rather than at the class level.  You *could* make all of your fields and methods public… but any competent programmer knows that they should not do that.  You only want to expose encapsulated functionality, not internal implementation.

In a module, packages work the same way.  A module descriptor should only export the packages that are intended for consumption by other modules.  Packages which are not exported are private to that module, and cannot be accessed by other modules.  That is a good thing.  That’s object-oriented design, just like private class members is.

The module system is explicitly not intended to replace Maven, Gradle, or Ivy.  From [the original specification](https://openjdk.org/projects/jigsaw/spec/reqs/#version-selection):

>In other words, this specification need not define yet another dependency-management mechanism. Maven, Ivy, and Gradle have all tackled this difficult problem. We should leave it to these and other build tools, and container applications, to discover and select a set of candidate modules for a given library or application.