[External] : Re: ClassHierarchyResolver using Reflection information

[Brian Goetz]

This is a good first step.  In fact, I was just tinkering with a similar 
patch -- I'll send you what I've got.  More inline.

On 3/22/2023 2:55 PM, Adam Sotona wrote:
>
> Based on the discussion in this thread I propose to make a first step 
> and adjust ClassHierarchy factory methods following way:
>
>   * ofCached(ClassHierarchyResolver resolver)
>

Yes, caching should be something that is wrapped around a CHR, not 
complected with resource parsing.  The one thing we lose is the 
optimization where we opportunistically infer that a class is an 
interface if we discover it in the `implements` section of a classfile 
-- but I don't mind saying goodbye to that optimization.

>   * ofClassLoading(ClassLoader loader)
>   * ofResourceParsing(ClassLoader loader)
>   * ofParsing(Function<ClassDesc, InputStream> classStreamResolver)
>

How do these last two differ?

>   * of(MethodHandles.Lookup lookup)
>   * of(Collection<ClassDesc> interfaces, Map<ClassDesc, ClassDesc>
>     classToSuperClass)
>
> So the default can be defined as:
>
> DEFAULT_CLASS_HIERARCHY_RESOLVER = 
> ofCached(ofResourceParsing(ClassLoader.getSystemClassLoader()).orElse(ofClassLoading(ClassLoader.getSystemClassLoader())));
>

I recommend making one more step: turn the static default field into a 
factory:

static ClassHierarchyResolver standardResolver() {
     return ClassHierarchyResolver.ofCached(ClassHierarchyResolver.ofResource(
             new Function<ClassDesc, InputStream>() {
                 @Override public InputStream apply(ClassDesc classDesc) {
                     return ClassLoader.getSystemResourceAsStream(Util.toInternalName(classDesc) +".class");
                 }
             }));
}

Also, I think ofCached() should optionally let you specify a Map factory; some users might prefer a bound LHM, or to forego
the synchronization if they know use will be single-threaded:

     CHR ofCached(CHR)
     CHR ofCached(CHR, Supplier<Map<ClassDesc, ClassHiearchyInfo>>)



> Please help me to polish exact methods naming.
>
> Thank you,
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230322/5a987b3a/attachment.htm>