RFR: 8304425: ClassHierarchyResolver from Reflection [v7]
Chen Liang
liach at openjdk.org
Tue May 9 15:09:54 UTC 2023
> 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 10 additional commits since the last revision:
- rename to ofClassLoading/ofResourceParsing
convert the default class provider to bypass security manager restrictions
- Merge branch 'master' into hierarchy-resolve
- 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 <turbanoff at 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/78c8f2f7..be9fa4d0
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=06
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=05-06
Stats: 356591 lines in 3790 files changed: 293420 ins; 37875 del; 25296 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
More information about the core-libs-dev
mailing list