Integrated: 8304425: ClassHierarchyResolver from Reflection

[Chen Liang]

On Fri, 17 Mar 2023 18:18:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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?

This pull request has now been integrated.

Changeset: ac3ce2bf
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac3ce2bf759735042480b846f3c1cf37a0843b8d
Stats:     401 lines in 10 files changed: 304 ins; 29 del; 68 mod

8304425: ClassHierarchyResolver from Reflection

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/13082