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

[Jorn Vernee]

On Wed, 19 Jun 2024 17:28:23 GMT, Maurizio Cimadamore <mcimadamore 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
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java line 105:
> 
>> 103:         return switch (method) {
>> 104:             case MethodRefEntry mre ->
>> 105:                     isRestrictedMethod(mre.owner().asSymbol(), mre.name().stringValue(), mre.typeSymbol());
> 
> Do we really need these two identical calls to `isRestrictedMethod` ? Note that both `MethodRefEntry` and `InterfaceMethodEntry` are subclasses of `MemberRefEntry`, so perhaps the other `isRestrictedMethod` can just take `MemberRefEntry`?
> 
> Or maybe we can have different factories in `MethodRef` one that takes `InterfaceMethodEntry` and another that takes `MemberRefEntry`.

I can do that, but I think this will always be a bit awkward since these types don't have a common super type that exposes the needed information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646571620