On Wed, 9 Apr 2025 16:00:52 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> `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
src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java
line 97:
> 95: }
> 96: Optional<ClassModel> modelOpt =
> systemClassResolver.lookup(methodRef.owner());
> 97: if (!modelOpt.isPresent()) {
Maybe add a comment here saying that restricted methods must be in system
classes?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24493#discussion_r2037610289
