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