RFR: 8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization [v3]

Jaikiran Pai jpai at openjdk.java.net
Wed May 25 09:20:57 UTC 2022


On Tue, 24 May 2022 13:07:08 GMT, liach <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 605:
>> 
>>> 603:         mv.visitLdcInsn(Type.getObjectType(dotToSlash(className)));
>>> 604:         mv.visitMethodInsn(INVOKEVIRTUAL, JL_CLASS,
>>> 605:                 "getClassLoader", "()" + LJL_CLASSLOADER, false);
>> 
>> Hello @liach, should this instead be using the (application supplied) `loader` returned by the call to `ProxyGenerator.getClassLoader()` or maybe the `loader` member in the `ProxyGenerator` itself?
>
> This is equivalent to `jdk.proxy5.$Proxy5.class.getClassLoader()` in Java source code, so this is exactly the application-supplied loader, which also uses the same loader as the previous behavior of `forName` calls.
> 
> If you want to pass the loader from `ProxyGenerator` to the proxy, it requires complex tricks. Hidden classes won't work due to serialization incompatibility; accessor methods would be defined in `jdk.internal` and exported specifically to the proxy modules, but writing a class so each proxy gets its loader while what I wrote can already do is overkill.

Thank you @liach for that detail.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8800


More information about the core-libs-dev mailing list