What is 'reliable configuration' in JPMS, and which classpath failures does it eliminate?

## Recap: the classpath's weaknesses The **classpath** is the pre-module mechanism for telling the JVM where to find classes: a flat, ordered list of JARs and directories. It has three well-known failure modes: 1. **Missing dependency, found late.** Nothing records that `app.jar` needs `lib.jar`. If `lib.jar` is absent, everything compiles and even starts; the failure (`NoClassDefFoundError` / `ClassNotFoundException`) appears only when the code path that touches the missing class finally runs — possibly hours in, possibly only in production. 2. **Shadowing / first-wins.** If two JARs contain a class with the same fully-qualified name, the JVM uses whichever appears first on the classpath and silently ignores the other. You get the wrong version with no warning. 3. **Split packages.** A **package** (e.g. `com.example.util`) is meant to be one cohesive namespace, but on the classpath its classes can be scattered across several JARs. This breaks visibility assumptions and causes subtle bugs. ## What 'reliable configuration' means **Reliable configuration** is JPMS's guarantee that the set of modules an application uses is **complete, consistent, and unambiguous — verified before the application's `main` runs**. The module system performs a step called **resolution**: starting from a root module, it reads each module's descriptor, follows every `requires` directive, and transitively pulls in all needed modules to build the **module graph**. If anything is wrong with that graph, resolution fails immediately. ## The specific failures it eliminates - **Missing modules → fast, clear failure.** If a `requires` names a module that is not present on the modulepath, resolution aborts at startup with an error like `module X not found, required by Y`. You learn about the gap before any business logic executes, and the message tells you exactly which dependency is missing and who needs it. - **Duplicate modules → rejected.** The same module supplied twice in the same configuration is an error; you cannot accidentally load two copies. - **Split packages → rejected.** A package must be owned by **exactly one** module in a given configuration. If two readable modules both contain package `com.example.util`, resolution fails. This enforces that a namespace is cohesive and lives in one place. - **No silent shadowing.** Because each package is owned by exactly one module and resolution is graph-based, there is no 'first JAR on the list wins' ambiguity. A class has a single, well-defined provider. ## Why 'before it runs' is the key phrase The value is the **timing**: the difference between a startup error and a runtime error. Classpath problems were notorious for hiding until an unlucky code path executed. JPMS shifts those checks **left** — to resolution time — turning them into deterministic, immediately-visible failures with names attached. ## How it relates to strong encapsulation Reliable configuration is about *which* modules and *what* dependencies; **strong encapsulation** (the sibling goal) is about *what within a module is reachable*. Reliable configuration ensures the graph is sound; strong encapsulation ensures you can only touch the exported parts of the modules in that graph. Together they make the dependency story explicit and enforced. ## A concrete picture If module `A` has `requires B;` and `B` is absent, the old world started fine and blew up later. The module world prints a resolution error at launch naming both `A` and the missing `B`. That single behavioural change is the heart of reliable configuration.