Two classes both declare the package com.acme.util, but they are defined by different class loaders. Can one access the other's package-private members? Explain what the JVM treats as 'the same package' at run time.

## Two notions of "package" At the **source** level, a package is just the name in the `package` declaration; it determines default-access visibility as the language spec describes. At **run time**, the JVM works with a **run-time package**: a package name *together with the defining class loader of the classes in it*. Two classes are in the same run-time package only if they have the same package name **and** the same defining loader. This is the direct analogue of type identity being *(binary name, defining loader)*. Package membership inherits the same rule because it is derived from the same loading event. ## What that means for access Default (package-private) access, and `protected` access in its package-local aspect, are checked at **resolution time** against run-time packages. If the accessing class and the accessed member's class have the same package name but different defining loaders, resolution fails and the JVM throws `IllegalAccessError`. The compile-time/run-time asymmetry is what makes this surprising: `javac` sees only source package names, so the code compiles. The error surfaces the first time the offending symbolic reference is resolved, which may be well into execution. A related consequence: `Class.getPackage()` / `getPackageName()` return the name, but two `Package` objects obtained from classes with different defining loaders are distinct — again, the name alone is not the identity. ## Why the JVM does it this way Security. Package-private access is an intentional trust boundary: classes that ship together in a package may see each other's internals. If the boundary were keyed on the *name* alone, anyone could write a class declaring an existing package name, get it loaded, and read or call package-private members of that package's classes — a trivial escalation against library and platform internals. Binding the run-time package to the defining loader closes that: your injected class is only in the same run-time package if it was defined by the *same loader* as the classes it wants to reach — that is, if it was already trusted enough to be loaded from the same place. As a second, absolute line of defense the JVM refuses to let user-defined loaders define classes in `java.*` packages at all. Sealing (a jar manifest attribute) provides a complementary, packaging-level guarantee: all classes of a sealed package must come from the same jar. ## Interaction with the module system Since Java 9, named modules add a further layer on top: - A package must not be **split** across two named modules; the module system rejects such configurations, which removes a whole class of ambiguity that existed on the class path. - Access to a package's types from outside its module requires an explicit `exports` (or `opens` for deep reflection), independent of the run-time-package rule. So modern access control is layered: module readability and exports first, then run-time package and the class-level access flags. The run-time package rule did not go away; the module system sits above it. ## Where you actually meet this - **Instrumentation and bytecode generation.** Generated classes are commonly placed in the same package as the class they augment so they can touch package-private members. That only works if they are defined by *the same loader* — which is why generation APIs offer to define classes as a "nestmate" or into the target class's loader/lookup context rather than into an ad-hoc loader. - **Test frameworks** that generate helpers in the package under test have the same requirement. - **Container/plugin setups** where a jar's classes end up split across a shared loader and an application loader: half the package can no longer see the other half's internals, producing `IllegalAccessError` at run time with no compile-time warning. - **Mocking and proxying libraries** hitting package-private methods must arrange loader-compatible definition, not merely matching names. ## The rule to carry "Same package" is never a statement about a string. At run time it means *same package name and same defining class loader* — and inside a module system, additionally *same module with the right exports*. Any tool or design that relies on package-private access must control **which loader defines the classes**, not just what they are named.