What is MethodHandles.privateLookupIn and when would you use it for cross-class or cross-module access?

### The need: reaching another class's internals A `Lookup` from `MethodHandles.lookup()` carries the access rights of the class that created it - it can resolve that class's own private members but generally **not** another class's private members. Frameworks (serialisers, ORMs, dependency injectors, dynamic proxies) frequently need exactly that deep access into types they did not write. Before Java 9 the tool was reflection's `setAccessible(true)`, which simply switched off the access check. The **module system** (Java 9+, "Project Jigsaw") introduced **strong encapsulation**: a module's internals are inaccessible from outside unless the module explicitly **exports** (for public API) or **opens** (for deep reflective access) the package. `setAccessible` now succeeds only when the target package is open to you. ### What privateLookupIn does ```java MethodHandles.Lookup target = MethodHandles.privateLookupIn(SomeClass.class, MethodHandles.lookup()); ``` It returns a **new Lookup whose lookup class is `SomeClass`** and whose access mode includes **PRIVATE** ("deep reflective access"). With it you can now do: ```java MethodHandle getter = target.findGetter(SomeClass.class, "secret", int.class); VarHandle vh = target.findVarHandle(SomeClass.class, "counter", long.class); ``` for members you could not otherwise reach. ### The permission rule (this is the crux) `privateLookupIn(T, caller)` succeeds only if the caller is genuinely allowed to **teleport** into `T`'s context. Concretely, the target type's module must grant access to the caller's module: - if both classes are in the **same module**, it works (within normal rules); - across modules, the target's module must **`opens`** the target's package to the caller's module (an open module, an `opens pkg to caller.module` directive, or a runtime `--add-opens`), and the modules must read each other appropriately; - the caller's `Lookup` must itself have full capability (a `publicLookup()` is not enough). If these are not satisfied, `privateLookupIn` throws **`IllegalAccessException`**. So it does not *break* encapsulation; it *uses* the access the module owner has chosen to grant. ### Why it is better than setAccessible - **Capability-based:** you must already hold a valid caller `Lookup` and the module must consent - access is a transferable capability, not a global override. - **Honours the module system:** it cannot punch through a closed module that never opted in. - **Unlocks VarHandles, hidden classes, and Lookup.defineClass:** the modern dynamic-language and framework toolkit is built on the privileged `Lookup`, not on `setAccessible`. - **Auditable:** the grant lives in `module-info` (`opens`) or explicit `--add-opens` flags, so the trust boundary is visible. ### Typical uses (principal context) - **Serialization / mapping frameworks** that read and write private fields with `VarHandle`s for speed and correctness (including final-field semantics). - **Bytecode-light proxy / interceptor frameworks** that need to call private/super methods of a target. - **Defining hidden classes** (`Lookup.defineHiddenClass`) for runtime-generated implementations that are not discoverable by name - the basis of modern lambda/proxy generation. - **Bridging legacy reflective frameworks** onto the handle/VarHandle world while staying module-clean. ### Trade-offs and cautions - It still requires the target module's cooperation; you cannot use it to defeat a deliberately sealed module (good for security, sometimes inconvenient). - It is powerful: a leaked privileged `Lookup` is a capability someone else can use, so do not hand full lookups across trust boundaries casually. - For cross-version libraries, you may need a fallback because the required `opens` may be absent at runtime. ### Mental model Think of a `Lookup` as a keycard encoding *who you are and where you may go*. `privateLookupIn` is asking the building (the target module) to issue you a keycard for one specific floor (the target class) at full clearance - it only works if that floor's owner has put your name on the access list (`opens`). It is delegation of an existing right, not lock-picking.