Understand the module system basics, how to create and build modules, and how to increase maintainability and encapsulation.

Use open packages and open modules to allow reflective access to otherwise encapsulated packages.

Use requires static for optional dependencies - modules required this way are accessible at compile time but can be absent at run time.

Use requires transitive to imply readability, where a module passes its dependency on another module on, allowing other modules to read it without explicitly depending on it.

Use exports ... to ... and opens ... to ... to limit accessibility of exported or opened packages to specific modules.

Decouple users and providers of a service with Java's ServiceLoader API, which the module system makes a first-class concept with uses and provides directives in the module declaration.

All JARs on the class path, modular or not, become part of the unnamed module. This makes 'everything a module', while the chaos of the class path can live on.

Plain JARs on the module path become automatic modules, where they can act as a bridge from modular JARs to the class path.

Learn how to use the javac, jar, and java commands to compile, package, and launch your modular application by hand - good to know even though build tools do most of the heavy lifting.

Strong encapsulation is a corner stone of the module system. It avoids (accidental) use of internal APIs, chiefly non-public types/members in java.* packages and much of sun.* and com.sun.*.

The command line flags --add-exports and --add-opens give access to an internal API, be it part of the JDK or a dependency, by exporting a package at compile or run time or by opening it for reflection at run time.

The command line options --add-modules and --add-reads expand the module graph generated by the module system with additional modules (nodes) and readability relations (edges).