RFR: 8242888: Convert dynamic proxy to hidden classes
Remi Forax
forax at univ-mlv.fr
Thu May 23 11:43:38 UTC 2024
----- Original Message -----
> From: "Chen Liang" <liach at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>, "hotspot-dev" <hotspot-dev at openjdk.org>, kulla-dev at openjdk.org
> Sent: Thursday, May 23, 2024 1:28:01 PM
> Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes
> On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:
>
>> Please review this change that convert dynamic proxies implementations to hidden
>> classes, intended to target JDK 24.
>>
>> Summary:
>> 1. Adds new implementation while preserving the old implementation behind
>> `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
>> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in
>> native code; I updated native code to reuse that ClassLoader for Proxy support.
>> 3. ProxyGenerator changes mainly involve using Class data to pass Method list
>> (accessed in a single condy) and removal of obsolete setup code generation.
>>
>> Testing: tier1 and tier2 have no related failures.
>>
>> Comment: Since #8278, Proxy has been converted to ClassFile API, and
>> infrastructure has changed; now, the migration to hidden classes is much
>> cleaner and has less impact, such as preserving ProtectionDomain and dynamic
>> module without "anchor classes", and avoiding java.lang.invoke package.
>
> A CSR targeting 24 describing the compatibility concerns and behavioral
> differences is here, somehow not linked by skara:
> https://bugs.openjdk.org/browse/JDK-8332770
> The incompatibilities were much greater in the previous iterations of this
> issue, such as in dynamic modules, serialization, and in proxy class protection
> domain. Now these aspects are addressed by this patch, the only real one left
> is the change in stack trace. Feel free to raise other incompatibilities you
> have discovered.
I wonder if instead of using hidden classes, we should not use usual named classes and add a new Lookup.defineClass() that takes a classData as parameter.
This will solve the both the problem of the stacktrace and the problem of the roundtrip proxyClass != Class.forName(proxyClass.getName()).
RĂ©mi
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679
More information about the core-libs-dev
mailing list