On Mon, 20 Mar 2023 11:07:23 GMT, Adam Sotona <asot...@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? > > Marked as reviewed by asotona (Committer). @asotona So should I simply throw an `IllegalAccessError` when the Lookup encounters a `IllegalAccessException`, or should I return null? I favor throwing an `IllegalAccessError` as the lookup represents bytecode accessibility, and shall it fail to access, the generated bytecode will fail to access the specified superclass as well. ------------- PR: https://git.openjdk.org/jdk/pull/13082
