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.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 81: > 79: > 80: Map<ScannedModule, Map<ClassDesc, List<RestrictedUse>>> > allRestrictedMethods; > 81: try(ClassResolver classesToScan = > ClassResolver.forScannedModules(modulesToScan, version); Could it make sense here to "chain" the two resolvers into one, and just pass the chained one to the restricted finder? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646553850
