Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v2]
On Wed, 19 Jun 2024 19:00:22 GMT, Jorn Vernee 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 one additional > commit since the last revision: > > Update src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java > > Co-authored-by: Maurizio Cimadamore > <54672762+mcimadam...@users.noreply.github.com> I've also added a first version of the man page for the tool. I'm not every familiar with the JDK man pages, as I rarely use them myself, so there's probably things missing. Please let me know. - PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2179460047
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v2]
On Wed, 19 Jun 2024 17:41:36 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java >> >> Co-authored-by: Maurizio Cimadamore >> <54672762+mcimadam...@users.noreply.github.com> > > src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java > line 76: > >> 74: URI location = m.reference().location().orElseThrow(); >> 75: Path path = Path.of(location); >> 76: checkRegularJar(path); > > if exploded modules aren't supported (as discussed offline), maybe the error > message generated here should be more specific? What do you suggest? Just a note in the error message that exploded modules/class paths are not supported? - PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646643125
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v2]
On Wed, 19 Jun 2024 17:45:14 GMT, Jorn Vernee wrote: >> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java >> line 120: >> >>> 118: Optional info = >>> systemClassResolver.lookup(methodRef.owner()); >>> 119: if (!info.isPresent()) { >>> 120: return false; >> >> Is this just `false` or maybe a warning that a certain owner could not be >> resolved (maybe if running with enough debug options) ? > > Yes, thought about that yesterday as well. Good catch Thinking a bit more: we also use the optional being empty to know if the owner is not a system class, so I think this code here is what we want. We can however throw an exception if a class is not found in `SystemClassResolver::lookup`. Since, if a class is inside a system module package, it should be found as well (unless the user sets the release to the wrong version). - PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646606901
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v2]
On Wed, 19 Jun 2024 18:09:15 GMT, Jorn Vernee wrote: > these types don't have a common super type that exposes the needed information No wait, they actually do :) That's just `MemberRefEntry`. - PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646604479
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v2]
> 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 one additional commit since the last revision: Update src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java Co-authored-by: Maurizio Cimadamore <54672762+mcimadam...@users.noreply.github.com> - Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/9e8dad03..861965b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774 PR: https://git.openjdk.org/jdk/pull/19774