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

[Jorn Vernee]

On Tue, 18 Jun 2024 16:30:37 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

src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 93:

> 91:     }
> 92: 
> 93:     public PlatformDescription getPlatformTrusted(String platformName) {

I noticed that `getPlatform` was not throwing an exception if the release was not valid, which then later results in an NPE. I've added an explicit check here instead. The caller can then catch the exception.

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

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