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.go...@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, liangchenb...@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
