Summary

Reimplement dynamic proxy with hidden classes. This is offered as an experimental option, toggleable with -Djdk.reflect.useHiddenProxy=true.

Problem

1. Dynamic proxies are implementation artifacts, yet they show up in stacktraces;
2. Dynamic proxies are defined to ClassLoaders, and their life is bound to the class loader; it would be too costly to create new ClassLoaders to allow easy unloading of Dynamic proxies.
3. Dynamic proxies cannot easily access the Method objects for the methods it implement, and need extra code to setup.

Solution

Change dynamic proxies implementation to be hidden classes, being hidden in stacktraces and flexible in unloading. (Full unloading support needs further cache implementation update.) As hidden classes, they now access the Method objects via classdata, avoiding extra computations and allowing implementation classes to reach the physical classfile limits later.

Since we anticipate this to have compatibility risk as Proxy class objects are used by serialization, we do not enable this implementation by default; it has to be opt-in with -Djdk.reflect.useHiddenProxy=true to allow early adoptions.

Since the hidden proxy implementation requires MethodHandle-based serialization constructor implementation, VM will fail with an error if both -Djdk.reflect.useHiddenProxy=true and -Djdk.reflect.useOldSerializableConstructor=true are passed.

Specification

There is no change to Proxy specification. The new implementation still conforms to those specification, such as serialization, system protection domain, and dynamic module.