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

Alan Bateman alanb at openjdk.org
Fri Jun 28 16:57:22 UTC 2024


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

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 69:

> 67:         }
> 68:         Configuration config = Configuration.resolveAndBind(moduleFinder, List.of(systemConfiguration()),
> 69:                 ModuleFinder.of(), rootModules);

I think the module path should work like other tools so the "moduleFinder" should be "after" finder, not the "before" finder. In other words, the modules that are observable on the application module path don't override the system modules. If you want you can use an instance method here, like this:

`systemConfiguration().resovleAndBind(ModuleFinder.of(), moduleFinder, rootModules)`

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

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


More information about the compiler-dev mailing list