On Wed, 19 Jun 2024 21:13:33 GMT, Jorn Vernee <[email protected]> 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 two additional
> commits since the last revision:
>
> - review comments
> - add man page
src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java
line 89:
> 87: throw new JNativeScanFatalError("Error while
> processing method: " +
> 88: MethodRef.ofModel(methodModel), e);
> 89: }
I'm re-wrapping the exception here, thrown from `SystemClassResolver::lookup`,
in order to include the method that called the missing system class in the
error message as well. (See also the code added in `Main` to print out an
exception cause if it is a `JNativeScanFatalError`).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646689741
