On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee <jver...@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
