Java Reflection — setAccessible Fails on JDK 9+

How the JVM Actually Loads Classes — The Foundation of Reflection

Before you can understand Reflection, you need to understand what happens when the JVM loads a class. Every time the classloader brings a .class file into memory, the JVM creates a single, unique java.lang.Class object for it. This Class object is the crown jewel — it's a live, runtime representation of everything the compiler knew about that class: its name, fields, methods, constructors, annotations, superclass, and interfaces.

This Class object lives in the Method Area (or Metaspace in Java 8+) and is shared across all instances of that class. When you call someObject.getClass() or write MyClass.class, you're grabbing a reference to that same singleton object.

Reflection is simply the API built around this Class object. The java.lang.reflect package gives you Field, Method, Constructor, and Modifier — all of which are views into data the JVM already holds. You're not doing anything supernatural. You're asking the JVM to tell you what it already knows.

The key insight: Reflection doesn't generate new information. It exposes existing metadata that the compiler baked into the bytecode. That's why it works — and also why it can break when that metadata is stripped by obfuscators or ahead-of-time compilers.

Invoking Methods and Mutating Private Fields at Runtime

Inspecting a class is just the beginning. The real power — and the real danger — of Reflection is the ability to invoke methods and read or write fields that were never meant to be touched from outside the class.

To call a method reflectively, you get a Method object and call invoke() on it, passing the target instance and arguments. For private methods, you must call setAccessible(true) first. This bypasses Java's access control checks — a door the JVM keeps locked by default, but which you can unlock with this single call.

Field mutation works the same way. You get a Field, call setAccessible(true), and then call field.set(instance, newValue). You've just written to a private field without a setter. Hibernate uses this exact mechanism to populate entity fields from database results without requiring public setters.

The danger is real: setAccessible(true) doesn't just bypass encapsulation for your code — it can silently corrupt object invariants if you write an invalid value. A private field named connectionPoolSize might have guards in its setter that enforce a minimum value. When you bypass the setter via reflection, those guards don't run. You own the consequences.

In Java 9+, the module system adds an extra layer. Even setAccessible(true) can throw an InaccessibleObjectException if the target module doesn't open its package. This is intentional — it closes a loophole that existed for decades.

Dynamic Object Creation and Generic Type Erasure at Runtime

One of Reflection's most powerful — and most misunderstood — use cases is instantiating classes at runtime without knowing them at compile time. This is exactly how Spring creates your @Service beans, how Jackson deserializes JSON into POJOs, and how plugin systems load user-defined classes from external JARs.

You get the Constructor object from the Class, call setAccessible(true) if needed, and call newInstance() on the Constructor. Note: Class.newInstance() was deprecated in Java 9 because it silently propagated checked exceptions. Always use Constructor.newInstance() instead — it's explicit about exceptions.

Now for the tricky part: generics. Java uses type erasure, meaning generic type parameters like List<String> are compiled down to just List at the bytecode level. At runtime, Reflection can't tell you the difference between a List<String> and a List<Integer> — they're both raw List to the JVM.

However, there's a workaround. If a generic type appears as a field declaration, method parameter, or superclass, that information IS preserved in the bytecode as a signature attribute. You can recover it via getGenericType() on a Field, which returns a ParameterizedType. This is how Jackson knows which generic type to deserialize into.

Understanding this distinction — runtime erasure vs. signature-level retention — separates developers who truly understand Reflection from those who just use it.

Reflection Performance, Caching, and When to Avoid It

Reflection is not free. Before Java 21, invoking a method reflectively was roughly 10–50x slower than a direct call, primarily because the JVM can't apply standard JIT optimizations like inlining across a reflective call boundary. The JVM also performs security checks on every reflective access unless you've cached the accessible Member object.

The good news: most of that cost is in the lookup, not the invocation. Class.forName(), getDeclaredMethod(), and setAccessible() are the expensive operations — the actual invoke() call is much cheaper, especially after the JVM's inflation mechanism kicks in. After ~15 native invocations, the JVM generates bytecode stubs (inflation) for the reflective call, dramatically improving performance. You can control this with the sun.reflect.inflationThreshold system property, though touching internal properties in production is risky.

The production rule is simple: never look up. Always cache. Get your Method, Field, and Constructor objects once — ideally at startup — and reuse them. Store them in static fields or a ConcurrentHashMap keyed by class name. This is exactly what Spring does: it resolves all reflection targets at application startup, then uses the cached Method objects for every subsequent bean operation.

Java 7+ MethodHandles (java.lang.invoke) offer a better alternative for hot paths. A MethodHandle behaves like a typed function pointer — the JVM CAN inline across it, making it nearly as fast as a direct call after JIT warmup. For any reflection-heavy code on a critical path, migrating from Method.invoke() to MethodHandle is the right production-grade move.

Security and Module System Implications of Reflection

Reflection is a double-edged sword. It gives you flexibility — but it also opens holes that attackers and misconfigurations can exploit.

The most dangerous pattern is using setAccessible(true) on objects you receive from external or untrusted sources. If your code calls setAccessible(true) on a Field or Method obtained from user-provided class names, an attacker can read and write private fields, invoke private constructors, and break encapsulation.

Java's SecurityManager (deprecated in Java 17 and removed in Java 18) was one line of defense. The modern defense is the Java module system (JPMS) introduced in Java 9. Modules can explicitly export or open packages. By default, java.base does not open its packages to unnamed modules, so reflective access to JDK internals is blocked.

When you need to grant reflective access, you add --add-opens flags at JVM startup: --add-opens java.base/java.lang=ALL-UNNAMED. But this is a global permission — it opens the package to ALL code, not just yours. A more secure approach is to move your code into a named module that explicitly opens its packages only to specific modules.

For applications that don't control the JVM flags (e.g., cloud environments, shared hosting), reflective access to internal APIs is simply impossible. Framework authors must design for this: use standard APIs, avoid private field access, and provide setter-based injection. Spring's reflection-based injection, for example, works without setAccessible on public methods and constructors, but for private fields it requires module openness.

Frequently Asked Questions