any other drawbacks. Please enlighten
me.
On Wed, Aug 25, 2021 at 5:22 AM Remi Forax wrote:
>
> - Original Message -
> > From: "-"
> > To: "Brian Goetz" , "core-libs-dev"
> >
> > Sent: Lundi 23 Août 2021 08:34:17
> > Subjec
On 25/08/2021 11:22, Remi Forax wrote:
:
In my opinion, what is missing is a java.lang.invoke.Proxy, the equivalent of
java.lang.reflect.Proxy but using defineHiddenClass + a bootstrap method +
method handles instead of the InvocationHandler + j.l.r.Method. With that,
implementing java.lang.in
- Original Message -
> From: "-"
> To: "Brian Goetz" , "core-libs-dev"
>
> Sent: Lundi 23 Août 2021 08:34:17
> Subject: Re: Implementing MethodHandleProxies#asInterfaceInstance with hidden
> classes
> Thanks for the quick reply!
&g
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
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.lan
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
(inc
