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? ------------- Commit messages: - 8304425: ClassHierarchyResolver from Reflection - ClassHierarchyResolver using Reflection Changes: https://git.openjdk.org/jdk/pull/13082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304425 Stats: 139 lines in 5 files changed: 129 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13082.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13082/head:pull/13082 PR: https://git.openjdk.org/jdk/pull/13082
