On Thu, 6 Apr 2023 19:33:51 GMT, Johannes Kuhn wrote:
>> This is good work.This needs some careful study on the security aspect.
>> I see the proxy class is in the same module of the interface, is non-public,
>> and it has a no-arg non-public constructor.
>>
>> Defining the proxy class i
On Thu, 6 Apr 2023 18:33:29 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 19:22:56 GMT, Mandy Chung wrote:
> This seems a concern if the target method handle should not have access to
> the class in that module.
MethodHandle access is checked when the MethodHandle is created.
For `@CallerSensitive` methods, the MethodHandle is additionally bound
On Thu, 6 Apr 2023 18:33:29 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Thu, 6 Apr 2023 18:33:29 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
