ClassHierarchyResolver changes for the Classfile object

[-]

(Sorry, forgot to cc classfile api dev)

For your performance impact concerns, I think we can probably keep caching
for the system class loader resource parsing CHR. But I think we will still
convert the field to a static method.

Should I incoporate all 3 changes in my patch?


> On Thu, Jun 1, 2023, 1:34 AM Adam Sotona <adam.sotona at oracle.com> wrote:
>
>>
>>
>>
>>
>> *From: *classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf
>> of liangchenblue at gmail.com <liangchenblue at gmail.com>
>> *Date: *Wednesday, 31 May 2023 8:26
>> *To: *classfile-api-dev <classfile-api-dev at openjdk.org>
>> *Subject: *ClassHierarchyResolver changes for the Classfile object
>>
>> Hello,
>> Since we are migrating to the Classfile object (8308899), which was
>> initiated by our observation that Class hierarchy resolvers shouldn't
>> always cache their results, I wonder what changes I should adapt to my
>> current patch (8304425, PR #13082).
>>
>> We have already decided a few API changes for the resolver:
>> 1. Remove the default hierarchy resolver (at least change to static
>> factories), caching is bound to Classfile lifetime
>>
>> Yes, but we need to check performance impact on existing use cases (where
>> to extra hold Classfile instance with cache).
>>
>>
>>
>>
>>
>> 2. Two new resolver factories: Bytecode/resource parsing and
>> classloading/reflection from a given classloader (The goal of this
>> patch)
>>
>>
>>
>> Yes.
>>
>>
>> 3. The resolution result ClassHierarchyInfo will be converted into an
>> interface; record is an implementation detail (TBD)
>>
>>
>>
>> This can go even further. To save footprint ClassHierarchyInfo does not
>> need to expose anything, it does not need to carry thisClass and all
>> interface infos can point to a singleton object, something like this:
>>
>>     /**
>>
>>      * *Information* *about* *a* *resolved* *class* *or* *interface.*
>>
>>      */
>>
>>     sealed interface *ClassHierarchyInfo*
>>
>>             permits ClassHierarchyImpl.*ClassHierarchyInfoImpl* {
>>
>>
>>
>>         /**
>>
>>          * {*@return* the {*@link* ClassHierarchyInfo} of an interface}
>>
>>          * no other information about interface is required
>>
>>          */
>>
>>         static *ClassHierarchyInfo* *ofInterface*() {
>>
>>             return ClassHierarchyImpl.*INTERFACE_INFO_INSTANCE*;
>>
>>         }
>>
>>
>>
>>         /**
>>
>>          * *@return* the {*@link* ClassHierarchyInfo} of an interface
>>
>>          * *@param* superClass information about super of the class is
>> required
>>
>>          */
>>
>>         static *ClassHierarchyInfo* *ofClass*(ClassDesc superClass) {
>>
>>             return new
>> ClassHierarchyImpl.ClassHierarchyInfoImpl(superClass);
>>
>>         }
>>
>>     }
>>
>>
>>
>> What should I do with my patch? Should I drop the changes to default
>> resolver (which adds security manager suppression) and move on with
>> the current content, or should I expand it to address all 3 planned
>> changes (despite some of them still in drafting phase) and accomodate
>> to the Classfile object? (We still have to decide about the default
>> resolver fo a Classfile object, esp. whether to have one or not)
>>
>>
>>
>> I’m not sure why the default class hierarchy resolver should call
>> AccessController.doPrivileged?
>>
>>
>>
>>
>> Thanks,
>>
>> Adam
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230601/47c92c6b/attachment.htm>