ClassHierarchyResolver changes for the Classfile object

[-]

I think I will leave the security manager patch to where we need it, and
will drop it from the CHR refactor.

On Thu, Jun 1, 2023, 3:53 PM Adam Sotona <adam.sotona at oracle.com> wrote:

> I understand the benefits having default class hierarchy resolver
> configuration its own privileged access to the system class loader, however
> such “default” probably should not be available for external use and even
> JDK-internal use differs case by case. I think it should be user
> responsibility to deal with security manager when needed.
>
>
>
> Thanks,
>
> Adam
>
>
>
>
>
> *From: *Mandy Chung <mandy.chung at oracle.com>
> *Date: *Thursday, 1 June 2023 2:47
> *To: *liangchenblue at gmail.com <liangchenblue at gmail.com>, Adam Sotona <
> adam.sotona at oracle.com>
> *Cc: *classfile-api-dev <classfile-api-dev at openjdk.org>
> *Subject: *Re: ClassHierarchyResolver changes for the Classfile object
>
> It's a question to the ClassHierarchyResolver interaction with the
> security manager.   Although it's deprecated for removal, we still need to
> consider when it's installed and whether the API would throw
> SecurityException due to the security permission check or the
> implementation is safe to use the system class loader loading resources
> with privilege.
>
> Mandy
>
> On 5/31/23 5:32 PM, - wrote:
>
> 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/e9b82df6/attachment-0001.htm>