On Fri, 17 Mar 2023 18:18:48 GMT, Chen Liang <li...@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? After thinking, I chose `IllegalArgumentException` for an error is not indicative here (as this should not throw an `IncompatibleClassChangeError`, the superclass of `IllegalAccessError`). I will keep the delegation to system classloader for default resolver for now, though it appears this is subject to discussion on the mailing list. ------------- PR: https://git.openjdk.org/jdk/pull/13082
