On Sat, 11 Mar 2023 13:45:23 GMT, Chen Liang <li...@openjdk.org> wrote:
>> Adam Sotona has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 196 commits: >> >> - Merge branch 'master' into JDK-8294961-proxy >> - Merge branch 'master' into JDK-8294961-proxy >> - Merge branch 'JDK-8294982' into JDK-8294961 >> - removed obsolete javadoc from implementation classes >> - minor fix in CodeBuilder and added test cases to LDCTest >> - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros >> - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and >> added test >> - Merge branch 'master' into JDK-8294982 >> - fixed new lines at end of file >> - package jdk.internal.classfile.jdktypes moved to >> jdk.internal.classfile.java.lang.constant >> - ... and 186 more: https://git.openjdk.org/jdk/compare/e26cc526...951b1bc7 > > src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 426: > >> 424: */ >> 425: localCache.computeIfAbsent(classDesc, cd -> { >> 426: try { > > This probably can be a factory method in ClassHierarchyResolver too, by > examining the reflection API via a ClassLoader/Lookup. I'm inclined to submit > a patch for improvement. > > Also, why does ProxyGenerator come with a custom ClassHierarchyResolver while > InnerClassLambdaMetafactory in 8294960 #12945 doesn't? Possible extensions of `ClassHierarchyResolver` factories, or maybe even extensions of the default resolver are on the table and I just planned to open this discussion. Here is specific case where original code passes `ClassLoader` down to to the ASM engine for class hierarchy resolution based on class loading. Classfile API has more flexibility in that area and can resolve class hierarchy based on provided minimal information. Default class hierarchy resolution is fast-scanning of classfiles provided by ClassLoader as resources. It is not necessary to resolve all dependencies nor load the classes. However this is one of the cases where I'm not sure the default does it right. The above code turns default class hierarchy resolution back to the original class-loading approach. In `InnerClassLambdaMetafactory` I didn't observed any `ClassLoader` beeing passed down to ASM, so it rely on the defaults. The right solution may be to extend the default class hierarchy resolution to fall back to class-loading when the resource form of the class is not available. A factory method can just replicate the same behavior with provided different `ClassLoader`. I'm open to any comments and suggestions. ------------- PR: https://git.openjdk.org/jdk/pull/10991
