ClassHierarchyResolver changes for the Classfile object

[Adam Sotona]

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/20230531/f4284fe4/attachment-0001.htm>