Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Fri, 28 Jun 2024 16:47:27 GMT, Alan Bateman wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> de-dupe on path, not module name
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
> line 105:
>
>> 103: for (String classPathEntry : classPathAttribute) {
>> 104: Path otherJar = parentDir != null
>> 105: ? parentDir.resolve(classPathEntry)
>
> We'lll need to create a follow on issue to re-examine this as the value of a
> Class-Path attribute aren't sequence of relative URIs (with an optional
> "file" URI scheme) rather than file paths. Treating it as a file path may
> work in some cases but won't work once you encounter cases that use escaping.
Okay, it seems that I didn't read the spec careful enough, and filtering valid
URLs in the Class-Path attribute is actually a bit tricky. Let's handle this in
a follow up.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659242843
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Mon, 24 Jun 2024 12:57:39 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: > > de-dupe on path, not module name src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 69: > 67: } > 68: Configuration config = Configuration.resolveAndBind(moduleFinder, > List.of(systemConfiguration()), > 69: ModuleFinder.of(), rootModules); I think the module path should work like other tools so the "moduleFinder" should be "after" finder, not the "before" finder. In other words, the modules that are observable on the application module path don't override the system modules. If you want you can use an instance method here, like this: `systemConfiguration().resovleAndBind(ModuleFinder.of(), moduleFinder, rootModules)` - PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659028434
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Mon, 24 Jun 2024 12:57:39 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:
>
> de-dupe on path, not module name
src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line
105:
> 103: for (String classPathEntry : classPathAttribute) {
> 104: Path otherJar = parentDir != null
> 105: ? parentDir.resolve(classPathEntry)
We'lll need to create a follow on issue to re-examine this as the value of a
Class-Path attribute aren't sequence of relative URIs (with an optional "file"
URI scheme) rather than file paths. Treating it as a file path may work in some
cases but won't work once you encounter cases that use escaping.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659018308
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Mon, 24 Jun 2024 12:57:39 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: > > de-dupe on path, not module name test/langtools/tools/jnativescan/TestJNativeScan.java line 33: > 31: * cases.classpath.app.App > 32: * cases.classpath.unnamed_package.UnnamedPackage > 33: * @run testng TestJNativeScan We've using JUnit rather than in TestNG for new tests, this one looks strange forward to move if we want. - PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659011377
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Mon, 24 Jun 2024 12:57:39 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: > > de-dupe on path, not module name Looks good to me. - Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2145411864
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Mon, 24 Jun 2024 12:57:39 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: > > de-dupe on path, not module name Fixed a small bug: https://github.com/openjdk/jdk/pull/19774/commits/40ca91ed47be7697cb720c1b1155d5192e262cc3 I think there's potentially more cleanup that can be done. `ClassResolver` is trying to do too many things atm, I think. It can both iterate over all classes, and do lookups of individual classes, but we only either use one or the other, either to find all classes to scan, or to lookup system classes (the system resolver doesn't even support iterating). I think `ClassResolver` would be better off if it just supported lookups, and then `NativeMethodFinder` operated on individual `ClassModules` instead of iterating over all classes. The iteration can be lifted into `JNativeScanTask::run`, and this spreads out the nesting a bit as well so code doesn't become too hard to follow. I sketched out that idea, and it looks better to me, but there's quite a lot of code motion, without any functional difference ([commit]), so I'll leave it for a followup (unless people want it in this PR). [commit]: https://github.com/JornVernee/jdk/compare/jnativescan...JornVernee:jdk:jnativescan_Refactor - PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2186538931
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
> 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: de-dupe on path, not module name - Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/a046f6fe..40ca91ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19774=08 - incr: https://webrevs.openjdk.org/?repo=jdk=19774=07-08 Stats: 22 lines in 2 files changed: 19 ins; 0 del; 3 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
