Implementing MethodHandleProxies#asInterfaceInstance with hidden classes

[-]

Thanks for the quick reply!

The main drawback, API wise, with LMF is that it does not accept
non-direct method handles [1], while the MHP is able accept any method
handle, such as native ones from JEP 389 [2]. LMF also lacks the
ability to restore a method handle from a wrapper instance. Using LMF
also requires user discretion on which methods to implement, and the
lookup's required privileges may change too. In general, MHP would be
more runtime-oriented and transient compared to LMF.

I am inclined toward a separate bytecode generation implementation for
the improved MHP asInterfaceInstance, somewhat similar to what's in
JEP 416's implementation [3]. The extra bridges for all compatible
methods, accessors to backing method handle/interface, potential to
expand to abstract classes, different hidden class modes would reduce
the commonalities between the two implementations and make
refactorings on LMF to support these MHP functionalities costly.

[1] https://github.com/openjdk/jdk/blob/b690f29699180149d33b6a83de10697790587a87/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java#L141
[2] https://openjdk.java.net/jeps/389#The-C-linker
[3] https://github.com/openjdk/jdk/blob/cff856f9df89293cbc8f2f1e977148cd6ece4f85/src/java.base/share/classes/jdk/internal/reflect/ClassByteBuilder.java


On Sun, Aug 22, 2021 at 9:26 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> 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