ClassHierarchyResolver changes for the Classfile object

[mandy.chung at oracle.com]

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.*
>
>     */
>
>     sealedinterface*/ClassHierarchyInfo/*
>
>     permitsClassHierarchyImpl./ClassHierarchyInfoImpl/ {
>
>     /**
>
>              * {*@return*the {*@link*ClassHierarchyInfo} ofaninterface}
>
>              * nootherinformationaboutinterfaceisrequired
>
>     */
>
>     static/ClassHierarchyInfo/ */ofInterface/*() {
>
>     returnClassHierarchyImpl./INTERFACE_INFO_INSTANCE/;
>
>             }
>
>     /**
>
>              * *@return*the {*@link*ClassHierarchyInfo} ofaninterface
>
>              * *@param*superClass
>     informationaboutsuperoftheclassisrequired
>
>     */
>
>     static/ClassHierarchyInfo/ */ofClass/*(ClassDesc superClass) {
>
>     returnnewClassHierarchyImpl.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/20230531/4c3699c6/attachment-0001.htm>