ClassHierarchyResolver using Reflection information

[Adam Sotona]

I like your proposal and I would like to see it as a fallback solution for DEFAULT_CLASS_HIERARCHY_RESOLVER when the class is not available as resource stream.

   /**
     * Default singleton instance of {@linkplain ClassHierarchyResolver}
     * using {@link ClassLoader#getSystemResourceAsStream(String)}
     * as the {@code ClassStreamResolver} with fallback to
     * {@link ClassLoader.getSystemClassLoader()} class loading resolver.
     */
    ClassHierarchyResolver DEFAULT_CLASS_HIERARCHY_RESOLVER
            = new ClassHierarchyImpl.CachedClassHierarchyResolver(
            new Function<ClassDesc, InputStream>() {
                @Override
                public InputStream apply(ClassDesc classDesc) {
                    return ClassLoader.getSystemResourceAsStream(Util.toInternalName(classDesc) + ".class");
                }
            }).orElse(ClassHierarchyResolver.of(ClassLoader.getSystemClassLoader()));

Thanks,
Adam

On 16.03.2023 17:05, "liangchenblue at gmail.com" <liangchenblue at gmail.com> wrote:

For context, in 8294961
https://github.com/openjdk/jdk/pull/10991/files#r1133086265 I wondered
about whether to use a hierarchy resolver for LambdaMetafactory, that
I think resolution may encounter problems as the default resolver may
not be able to resolve user-supplied interfaces.

In addition, many of the class file generation usages I've seen
include firing events via an event bus, calling patched external addon
code (as seen in Minecraft modding), in which Reflection-based
hierarchy resolution would work better than reading bytecode files.

Thus, I've prepared a patch creating ClassHierarchyResolver
https://github.com/openjdk/jdk/commit/0c888ba1e2953cf946012244446f4f8c05ba5d77
to ease up resolution with reflection, when a ClassLoader (for older
APIs) or a MethodHandle.Lookup (for modern APIs) is available.

Does this appear feasible?

Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230317/f17addcc/attachment.htm>