Summary
-------
JEP 416: Reimplement Core Reflection with Method Handles
Problem
-------
There are three different internal mechanisms for reflective operations:
- VM native methods,
- Dynamically generated bytecode stubs for Method::invoke and Constructor::newInstance, along with Unsafe field access for Field::get and set, and
- Method handles.
When we update `java.lang.reflect` and `java.lang.invoke` to support new language features, such as those envisioned in Project Valhalla, we must modify all three code paths, which is costly. In addition, the current implementation relies on special treatment by the VM of the generated bytecode, which is wrapped in subclasses of `jdk.internal.reflect.MagicAccessorImpl`:
- Accessibility is relaxed so that these classes can access inaccessible fields and methods of other classes,
- Verification is disabled to work around JLS ยง6.6.2 in order to support reflection on Object::clone, and
- A non-well-behaved class loader is used to work around some security and compatibility issues.
Solution
--------
Reimplement `java.lang.reflect.Method`, `Constructor`, and `Field` with `java.lang.invoke` method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the `java.lang.reflect` and `java.lang.invoke` APIs.
Specification
-------------
Code that depends upon highly implementation-specific and undocumented aspects of the existing implementation may be impacted. To mitigate this compatibility risk, as a workaround you can enable the old implementation via `-Djdk.reflect.useDirectMethodHandle=false`.
The old core reflection implementation will be removed in a later release.
The `-Djdk.reflect.useDirectMethodHandle=false` workaround will stop working at that point.