ClassHierarchyResolver changes for the Classfile object

- liangchenblue at gmail.com
Wed May 31 06:26:38 UTC 2023


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
2. Two new resolver factories: Bytecode/resource parsing and
classloading/reflection from a given classloader (The goal of this
patch)
3. The resolution result ClassHierarchyInfo will be converted into an
interface; record is an implementation detail (TBD)

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)

Chen Liang


More information about the classfile-api-dev mailing list