Implementation of JEP 416: Reimplement Core Reflection with Method Handle

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.