Implementing MethodHandleProxies#asInterfaceInstance with hidden classes

[Brian Goetz]

This was an early attempt at the functionality provided by LambdaMetafactory.  It could probably be reimplemented on top of that, but probably could be deprecated in favor of LMF as well. 

Sent from my iPad

> On Aug 22, 2021, at 10:08 PM, liangchenblue at gmail.com wrote:
> 
> Currently, java.lang.invoke.MethodHandleProxies#asInterfaceInstance [1] is
> implemented with java.lang.reflect.Proxy. After looking at its public API,
> including Javadoc, it seems that MethodHandleProxies would benefit from a
> hidden class implementation without changing its public API definition
> (including Javadocs).
> 
> Recently, there is JEP 416 [2] for reimplementing reflection based on
> method handles. This implementation utilizes hidden classes with method
> handles passed in classdata and retrieved to condy, which allows generic
> method handles (beyond regular constable ones) to be optimized in method
> calls. Similarly, for MethodHandleProxies, hidden classes allow the
> implementations to detach from classloaders and be freely recyclable; they
> can use class data to store the adapted method handles (which can
> significantly speed up invocations); and it can allow it to support
> implementing single-abstract-method abstract classes in the future (as
> discussed in its Javadoc) as well, with only minor tweaks.
> 
> Does this sound feasible? I want to ensure it is a good idea before any
> implementation is attempted. If there is any issue with this vision, please
> don't hesitate to point it out. Feel free to comment, too! If this looks
> good, I hope an issue can be created for it.
> 
> Best
> 
> [1]
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/MethodHandleProxies.html
> [2] https://openjdk.java.net/jeps/416