Summary

Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles

Problem

Current implementation of sun.reflect.ReflectionFactory::newConstructorForSerialization generates bytecode that does not conform verification rules. Hence VM has a special case to skip verification for all MagicAccessorImpl subclasses. Reimplementing it with method handles allow to remove the old crufty bytecode generator as well as the VM special case in skipping verification for certain classes.

Solution

Reimplement ReflectionFactory::newConstructorForSerialization with method handles

Specification

It's expected that this change has very low compatibility risk.

In case if customers run into any issue, an undocumented system property -Djdk.reflect.useOldSerializableConstructor=true can be set to use the old implementation as a workaround.

If ReflectionFactory::newConstructorForSerialization is called with C class and a constructor whose declaring class is A but A is not the superclass of C, the old implementation returns an ill-formed constructor and if newInstance is invoked, the behavior is unspecified. The new implementation of ReflectionFactory::newConstructorForSerialization throws UnsupportedOperationException instead.