ClassHierarchyResolver changes for the Classfile object

[mandy.chung at oracle.com]

I don't have an opinion as I'm not close to this area.   The javadoc 
needs to specify `SecurityException` be thrown if that's the design.


Mandy

On 6/1/23 12:53 AM, Adam Sotona 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.*
>
>         */
>
>         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/20230601/825490c8/attachment-0001.htm>