On Tue, 2 May 2023 21:22:16 GMT, Chen Liang <li...@openjdk.org> 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. Does not allow future expansion to support SAM[^1] abstract classes >> 3. Slow (in fact, very slow) >> >> This patch addresses all 3 problems: >> 1. It implements proxies with one hidden class for each requested interface >> and replaced WrapperInstance inheritance with a check to the class data. >> This can avoid unexpected passing of `instanceof`, and avoids the nasty >> problem of exporting a JDK interface to a dynamic module to ensure access. >> 2. This patch obtains already generated classes from a ClassValue by the >> requested interface type; the ClassValue can later be updated to compute >> implementation generation for abstract classes as well. >> 3. This patch's generated hidden classes has call performance on par with >> those of lambda expressions; the creation performance is slightly less than >> that of LambdaMetafactory: >> https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224 >> >> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's >> no longer applicable. Tests in `jdk/java/lang/invoke` and >> `jdk/java/lang/reflect` pass. >> >> [^1]: single abstract method > > Chen Liang has updated the pull request incrementally with one additional > commit since the last revision: > > Minor cleanup, attempt to migrate lookup validation blocked by security > manager Also, looking at #10024, should the proxy classes generated have stable names, such as by incorporating the name of the interface in the module/package name? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1533665503
