RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]

[Jorn Vernee]

On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>>     main.Main::main(String[])void references restricted methods:
>>       java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>>     main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   de-dupe on path, not module name

Fixed a small bug: https://github.com/openjdk/jdk/pull/19774/commits/40ca91ed47be7697cb720c1b1155d5192e262cc3

I think there's potentially more cleanup that can be done. `ClassResolver` is trying to do too many things atm, I think. It can both iterate over all classes, and do lookups of individual classes, but we only either use one or the other, either to find all classes to scan, or to lookup system classes (the system resolver doesn't even support iterating). I think `ClassResolver` would be better off if it just supported lookups, and then `NativeMethodFinder` operated on individual `ClassModules` instead of iterating over all classes. The iteration can be lifted into `JNativeScanTask::run`, and this spreads out the nesting a bit as well so code doesn't become too hard to follow. I sketched out that idea, and it looks better to me, but there's quite a lot of code motion, without any functional difference ([commit]), so I'll leave it for a followup (unless people want it in this PR).

[commit]: https://github.com/JornVernee/jdk/compare/jnativescan...JornVernee:jdk:jnativescan_Refactor

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2186538931