A platform team is choosing how to enforce module boundaries across a large codebase: JVM visibility modifiers, compile-time; an architecture-test library like ArchUnit or Spring Modulith's ApplicationModules.verify(), test-time static analysis; or the Java Platform Module System, JPMS, runtime strong encapsulation. What does each actually guarantee, at what point in the pipeline does each one fail loudly, and what's the cost of over-relying on any single one?

## Three enforcement points, three stages The three enforcement points sit at different stages of the build/deploy pipeline and check fundamentally different things. - **Compiler-enforced visibility** — private/package-private/Kotlin internal — is checked by javac/kotlinc at compile time: a violation simply doesn't produce a `.class` file, and the scope is always small, one package in Java or one compilation module in Kotlin. - **Architecture tests**, ArchUnit and Spring Modulith's `ApplicationModules.verify()`, run later, as ordinary tests against already-compiled bytecode, walking the actual call/dependency graph and asserting structural rules that can span the whole codebase — layering, allowed module-to-module dependencies, naming conventions — none of which any single class's visibility modifier can express. - **JPMS's exports/opens** operate at the outermost point, runtime class-loading: the JVM itself checks module readability before it will link or reflectively access a class from another module, which is why it's the only one of the three that holds even against reflection unless a package is explicitly opened. ## Layered defense, because none of them is enough alone No single point is sufficient on its own, so treating them as a layered defense — analogous to defense-in-depth in security — is the practical pattern. | Mechanism | What it gives | What it costs | |---|---|---| | Compiler visibility | free and instantaneous | can't express cross-cutting rules or survive reflection | | Architecture tests | can express arbitrarily rich cross-cutting rules and catch violations early, at the commit | only see what's compiled and exercised by the build, and the rules themselves are code that needs maintenance and can be silently deleted, weakened, or bypassed under pressure since nothing physically stops a developer from doing so | | JPMS | provides the strongest, JVM-enforced guarantee, immune even to reflection | the highest adoption cost — every dependency in the graph needs to be a well-formed module, split packages become hard errors, and legitimate reflection-based frameworks need explicit opens grants that can end up re-widening the very hole you tried to close | ## What over-relying on one tier looks like 1. **A team that relies purely on visibility modifiers** finds their "hidden" internals still get reached by ORMs and DI containers via reflection, and can't express or enforce any rule that spans multiple mutually-visible packages, like layering, so architecturally significant boundaries silently erode with no automated signal. 2. **A team that relies purely on architecture tests** gets rich, whole-codebase rules, but those rules are just more code: they need to be written, kept accurate as the package structure evolves, and nothing stops someone from deleting or weakening a failing rule under deadline pressure the way a compile error can't simply be deleted to make it go away; the tests are also blind to anything the build doesn't compile or run. 3. **A team that goes all-in on JPMS** gets the strongest guarantee but pays the highest price: migrating a legacy dependency graph to well-formed modules is often a multi-quarter effort, automatic-module name fragility introduces its own new failure class, and every reflection-dependent library in the stack needs explicit opens accommodations revisited on every upgrade. ## Each tier's distinguishing failure mode - **Visibility-only enforcement:** the distinguishing failure mode is silent reflection-based leakage — nothing ever fails loudly, the "internal" class is just quietly reachable by any framework that wants it. - **Test-only enforcement:** the distinguishing failure mode is rule rot — a rule someone wrote two years ago either no longer matches the current package structure, so it passes green while checking nothing meaningful, or gets flagged as blocking and deleted in a hurry, with no JVM-level fallback once it's gone. - **Over-investing in JPMS:** the distinguishing failure mode is sunk-cost migration risk — teams spend months modularizing a dependency graph for boundaries a lighter architecture test would have caught at a fraction of the engineering cost, and then still need opens escape hatches for reflection-heavy frameworks that partially undo the guarantee anyway. ## The practical decision rule The practical decision rule most JVM shops land on: 1. Use compiler visibility for the free, always-on baseline. 2. Add architecture tests for the cross-cutting, deployable-unit-shaped rules where visibility alone can't reach. 3. Reserve full JPMS module-path adoption for cases that specifically need its JVM-enforced, reflection-proof guarantee — a library shipped to untrusted or adversarial consumers, or a genuine security boundary within the same process — because that's the only tier where its cost is clearly worth paying. ## Where it shows up — the two-tier pattern A concrete instance of the two-tier pattern, deliberately skipping full JPMS: Kotlin internal visibility hides each Spring Modulith module's implementation classes from other modules at compile time for free, while `ArchitectureTest` and `ModulithTest`, run as part of a fast local quality gate on every change, separately verify the allowed-dependency graph between modules and the internal layering within each module, catching violations neither internal alone nor human review would reliably catch, all without paying JPMS's module-path migration cost since the whole backend is one deployable application rather than a set of independently-versioned libraries handed to untrusted external consumers, which is exactly the scenario where JPMS's extra cost wouldn't currently be justified.