> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with > proper privileges, with tests. > > This addition is useful in case classes at runtime are not loaded from the > system class loader, such as Proxy. This is also useful to APIs that generate > bytecode with a `Lookup` object, such as a custom single-abstract-method > class implementations from a method handle. > > See > https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html > as well. > > Current questions, which I wish to discuss with @asotona: > 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? > This usually indicates the hierarchy resolver is set up improperly, and > proceeding may simply yield verification errors in class loading that are > hard to track. For bytecode-generating APIs, throwing access errors for the > Lookup eagerly is also more preferable than later silent generation failure. > 2. Whether the default resolver should be reading from jrt alone, reflection > alone, or jrt then reflection. I personally believe reflection alone is more > reliable, for classes may redefined with instrumentation or jfr, which may > not be reflected in the system resources. > 3. In addition, I don't think chaining system class loader reflection after > system resource retrieval is really meaningful: is there any case where > reflection always works while the system resource retrieval always fails?
Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into hierarchy-resolve - Test both cached and uncached resolvers - Update the class hierarchy resolver api as per mailing list last week - Merge branch 'master' into hierarchy-resolve - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java Co-authored-by: Andrey Turbanov <turban...@gmail.com> - Make lookup based resolver throw on illegal access eagerly - 8304425: ClassHierarchyResolver from Reflection - ClassHierarchyResolver using Reflection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13082/files - new: https://git.openjdk.org/jdk/pull/13082/files/655b0276..78c8f2f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=04-05 Stats: 6888 lines in 211 files changed: 4666 ins; 1269 del; 953 mod Patch: https://git.openjdk.org/jdk/pull/13082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13082/head:pull/13082 PR: https://git.openjdk.org/jdk/pull/13082
