> 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
On Sun, 7 May 2023 13:34:54 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 Mon, 8 May 2023 09:32:31 GMT, Maurizio Cimadamore
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove assertion, no longer true with teleport definition in MHP
>
> src/java.base/share/classes/java/lang/invoke/
On Mon, 8 May 2023 10:46:34 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line
>> 342:
>>
>>> 340:
>>> 341: // individual handle fields
>>> 342: clb.withField(ORIGINAL_TARGET_NAME, CD_MethodHandle,
>>> ACC_PRI
On Sun, 7 May 2023 13:34:54 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 Fri, 26 May 2023 18:39:53 GMT, Mandy Chung wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove assertion, no longer true with teleport definition in MHP
>
> src/java.base/share/classes/java/lang/invoke/MethodHa
On Fri, 26 May 2023 21:05:39 GMT, Chen Liang wrote:
> This approach also requires the Class loading checks since the interface is
> not unconditionally exported and fails security manager.
Are you referring to `ClassLoader::checkPackageAccess` change? As MHProxy
implements `sun.invoke.Wrappe
On Fri, 26 May 2023 21:23:32 GMT, Mandy Chung wrote:
>> John Rose argues against using class data for Leyden. Since class data is
>> the only known way to defend against user-manufactured annotations, I
>> switched back to an extra wrapper interface. This approach also requires the
>> Class lo
On Fri, 26 May 2023 21:06:36 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line
>> 209:
>>
>>> 207: if (intfc.isHidden())
>>> 208: throw newIllegalArgumentException("a hidden interface",
>>> intfc.getName());
>>> 209:
On Fri, 26 May 2023 21:31:40 GMT, Mandy Chung wrote:
>> Yes. Unfortunately, it fails at
>> https://github.com/openjdk/jdk/blob/bd21e68e679c41c98f39dd2fbd38270ae7d55ed9/src/java.base/share/classes/java/lang/SecurityManager.java#L1317
>> because a conditionally-exported package is considered a
>
On Fri, 26 May 2023 21:29:14 GMT, Chen Liang wrote:
>>> This approach also requires the Class loading checks since the interface is
>>> not unconditionally exported and fails security manager.
>>
>> Are you referring to `ClassLoader::checkPackageAccess` change? As MHProxy
>> implements `sun.
On Fri, 26 May 2023 22:03:40 GMT, Mandy Chung wrote:
>> If we keep a cache of all MHProxy classes, I think this would not need
>> `sun.invoke.WrapperInstance`. OTOH, `sun.invoke` does not have any other
>> class except `WrapperInstance` and the `ensureOriginalLookup` method would
>> need to
On Fri, 26 May 2023 22:05:06 GMT, Mandy Chung wrote:
>>> because a conditionally-exported package is considered a
>>> non-(unconditionally-)exported package.
>>
>> OK. I need to look into the right solution for this. The Proxy
>> implementation uses null protection domain to define the prox
On Fri, 26 May 2023 22:18:17 GMT, Chen Liang wrote:
>> If we can avoid implementing `sun.invoke.WrapperInstance`, this package
>> access check issue would go away. Do you think you can look into it?
>
> I think we can probably insert a static final field in a wrapper instance
> class to point
On Wed, 31 May 2023 00:01:56 GMT, Mandy Chung wrote:
> Is it more straight-forward to keep a `ClassValue` and each wrapper
> instance class has an entry of `TRUE` value; otherwise, `FALSE`?
Then we still need to obtain the implemented interface and original method
handle information every time
On Wed, 31 May 2023 00:48:18 GMT, Mandy Chung wrote:
>>> Is it more straight-forward to keep a `ClassValue` and each
>>> wrapper instance class has an entry of `TRUE` value; otherwise, `FALSE`?
>>
>> Then we still need to obtain the implemented interface and original method
>> handle informati
On Wed, 31 May 2023 00:27:24 GMT, Chen Liang wrote:
> Apparently, calling utility methods from sun.invoke, like the
> ensureOriginalLookup in this patch, also triggers this check.
It should not trigger `checkPackageAccess` if it does not implement the
interface AFAICT.
It would trigger modul
On Wed, 31 May 2023 00:49:22 GMT, Mandy Chung wrote:
>>> Apparently, calling utility methods from sun.invoke, like the
>>> ensureOriginalLookup in this patch, also triggers this check.
>>
>> It should not trigger `checkPackageAccess` if it does not implement the
>> interface AFAICT.
>>
>> It
On Wed, 31 May 2023 12:38:14 GMT, Johannes Kuhn wrote:
>>> Then we still need to obtain the implemented interface and original method
>>> handle information every time they are queried. Having these information
>>> (or the method handle providing access) computed early is more convenient.
>>
>
On Sun, 7 May 2023 13:34:54 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.
20 matches
Mail list logo
