> `jnativescan` uses the `ClassResolver` class to find both system classes, as > well as application classes. In principle, a class resolver supports both > iterating over all classes from that particular source, as well as looking up > classes by name. However, the `ClassResolver` for system classes doesn't > support iterating, and the lookup functionality for `ClassResolvers` from > other sources is never used (only iterating). > > This patch proposes to split the iterating functionality out of > `ClassResolver`. Clients that were using this functionality will switch to > using the iteration functionality that is available on `ClassFileSource` > directly (whose classes were previously being wrapped in a `ClassResolver`). > As a result of this latter change, we can now also let `NativeMethodFinder` > operate on individual classes. We just iterate over all the class file > sources in `JNativeScanTask`, and feed individual class models to > `NativeMethodFinder`. I think this is a good conceptual simplification of > `NativeMethodFinder`, > > Since `ClassResolver` is now only used for system classes, I've removed it, > leaving only its single implementation: `SystemClassResolver`. > > Testing: running `langtools_jnativescan` test suite.
Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into jnativescan_Refactor - bump copyright years - merge ClassResolver and SystemClassResolver - Simplify ClassResolver ------------- Changes: https://git.openjdk.org/jdk/pull/24493/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24493&range=01 Stats: 371 lines in 5 files changed: 147 ins; 191 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/24493.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24493/head:pull/24493 PR: https://git.openjdk.org/jdk/pull/24493
