ClassHierarchyResolver changes for the Classfile object

[Adam Sotona]

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<mailto:adam.sotona at oracle.com>> wrote:


From: classfile-api-dev <classfile-api-dev-retn at openjdk.org<mailto:classfile-api-dev-retn at openjdk.org>> on behalf of liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Date: Wednesday, 31 May 2023 8:26
To: classfile-api-dev <classfile-api-dev at openjdk.org<mailto: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/e286688d/attachment-0001.htm>