Module System (JPMS)

The classpath (-cp) is the old flat list of JARs where everything is visible to everything; code there forms the unnamed module. The module path (-p) is the JPMS list where each JAR is a module. A plain JAR is part of the unnamed module on the classpath, but an automatic module on the module path.

The classpath is a flat list of JARs/folders the JVM scans to find classes, with no boundaries between them. The module path holds modules that declare their names and dependencies in module-info, so the JVM resolves and enforces them.

Reliable configuration means the module system checks all dependencies up front. Each module declares what it needs with 'requires', so missing or duplicate modules are caught when the program starts instead of failing later with a runtime error.

Strong encapsulation means only the packages a module explicitly exports are usable by other modules. A public class in a non-exported package is hidden, so 'public' no longer means 'visible to everyone' — it means visible only within the module unless the package is exported.

A split package is when the same package name lives in two different modules. The module system forbids it because each package must belong to exactly one module. You fix it by merging the package into one module or moving the classes so the package exists in only one place.

JPMS has three kinds of modules: named modules (a JAR with a module-info.java declaring its name, exports, and requires), automatic modules (a plain JAR placed on the module path, getting an auto-derived name), and the unnamed module (everything on the old classpath).

Even on Java 9+, code loaded from the classpath isn't outside the module system — it all goes into one special bucket called the unnamed module. The unnamed module can read every other module and export all its packages.

exports lets other modules use a package's public types at compile time and run time. opens additionally lets other modules use reflection to reach into the package, including its private members.

In a module's module-info.java, the provider writes provides Service with Impl; to declare its implementation, and the consumer writes uses Service; to declare it loads that service. These two lines replace the old META-INF/services text file when using modules.

jlink is a JDK tool that assembles a custom, minimal Java runtime image containing only the modules your application actually needs, plus the JVM. The result is a smaller, self-contained runtime you can ship without requiring a separate JRE installation.

exports makes a package's public types visible at compile and run time. opens instead grants deep reflective access at runtime — letting frameworks read/set private fields and call private members via reflection. Frameworks like Jackson or Hibernate need opens, not just exports.

In Java 9+, internal JDK packages (like sun.misc.Unsafe) are encapsulated by their modules and no longer exported, so code that used them fails to compile or warns/breaks at runtime. The right fix is to switch to a supported public API; as a temporary workaround you can use --add-exports or --add-opens.

A module is a named group of related Java packages and resources. You declare it in a special file, module-info.java, at the root of your source code; it names the module and lists what it needs and what it shares.

Readability means one module is allowed to depend on another. Module A reads module B when A's module-info.java says requires B. Without that, A cannot use B's types at all.

An SPI is an interface (or abstract class) that other code provides implementations for. ServiceLoader.load(MyService.class) finds and loads those implementations at runtime, so your program can use plug-ins it wasn't compiled against.

jdeps is a JDK command-line tool that analyzes the dependencies of compiled Java classes and JARs. It shows which packages and modules your code depends on, and can flag use of internal JDK APIs.

requires transitive X means anyone who depends on your module automatically also gets to read module X, without listing it themselves. It is used when your public API exposes types from X, so callers can use those types.

JPMS does not allow module A to require module B while B also requires A (directly or through a chain). Cycles are banned so the module graph can be resolved in a clear order. You break a cycle by extracting the shared code into a third module, or by inverting a dependency with an interface.

An automatic module's name comes from the Automatic-Module-Name entry in the JAR's MANIFEST.MF if present. If not, Java derives it from the JAR filename (dropping the version and turning non-letters/digits into dots). Filename-derived names are risky because renaming the file changes the module name.

requires static X makes module X required when compiling but optional at run time. It is for things like annotations or optional integrations that you compile against but that do not need to be present when the app runs.

uses S declares that your module consumes a service of interface type S via ServiceLoader. provides S with Impl declares that your module supplies Impl as an implementation of S. Together they let modules discover implementations without a hard dependency on the provider.

The classpath is the old flat list of JARs with no module rules. The modulepath loads JARs as modules with their declared dependencies and exports. A plain JAR placed on the modulepath becomes an 'automatic module' — it gets a name and exports everything, so old libraries can be used as modules.

Bottom-up means modularizing your dependencies first, then your own code; top-down means modularizing your own application first while leaving libraries as automatic modules. Automatic modules (plain jars on the module path) and the classpath unnamed module let you mix modular and non-modular code so you can migrate gradually.

The unnamed module has no name, and a module-info file declares dependencies by name (requires X). With no name to write, a named module literally cannot require the unnamed module, so it cannot see any code left on the classpath.

You can run with both -cp and -p at once. JARs you move onto the module path become modules (named or automatic); the rest stay classpath code in the unnamed module. You usually migrate from the leaf libraries inward because named modules can't see classpath code.

At startup the JVM reads each module's module-info, starts from a root module, follows its requires clauses to build a dependency graph, and verifies there are no missing modules, duplicate names, or split packages. The classpath does none of this — it just searches JARs in order when a class is needed.

The framework is using reflection to reach into your code's private members, but your package is not opened. Modules block reflective access by default. Fix it by adding opens yourpackage; (or opens yourpackage to the.framework;) in module-info.java.

Yes. Before modules, public meant accessible everywhere. With modules, a public type is only accessible from another module if its package is also exported and the other module reads yours. So public no longer guarantees access.

ServiceConfigurationError is thrown when a declared provider can't be loaded or instantiated — bad class name, no public no-arg constructor, or it doesn't implement the service. It surfaces while you iterate the ServiceLoader, not when you call load(). Typical pitfalls: forgetting uses on the module path, stale META-INF/services entries, and missing constructors.