ClassHierarchyResolver changes for the Classfile object

[-]

The doPrivileged is from Mandy Chung's modification to my patch of
reimplementation of MethodHandleProxies.asInterfaceInstance. It allows
system code to fetch from system classloader with security manager, but I
can just leave this change to be part of that patch instead.

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/0a477955/attachment.htm>