On Thu, 16 Mar 2023 13:21:38 GMT, Adam Sotona <asot...@openjdk.org> wrote:
>> 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.
I was thinking of implementing a class resolution via Reflection API with the
`MethodHandles.Lookup` passed into `LambdaMetafactory` for correctness. Could
it be that Lambda bytecode is too simple (as it's just calling a method handle
in an instance method and a constructor, in a class extending Object and
implementing a few interfaces) so the class hierarchy resolution wasn't
critical?
-------------
PR: https://git.openjdk.org/jdk/pull/10991
