On Wed, 19 Jun 2024 17:28:23 GMT, Maurizio Cimadamore <mcimadam...@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/RestrictedMethodFinder.java > line 105: > >> 103: return switch (method) { >> 104: case MethodRefEntry mre -> >> 105: isRestrictedMethod(mre.owner().asSymbol(), >> mre.name().stringValue(), mre.typeSymbol()); > > Do we really need these two identical calls to `isRestrictedMethod` ? Note > that both `MethodRefEntry` and `InterfaceMethodEntry` are subclasses of > `MemberRefEntry`, so perhaps the other `isRestrictedMethod` can just take > `MemberRefEntry`? > > Or maybe we can have different factories in `MethodRef` one that takes > `InterfaceMethodEntry` and another that takes `MemberRefEntry`. I can do that, but I think this will always be a bit awkward since these types don't have a common super type that exposes the needed information. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646571620