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/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`.

src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java
 line 120:

> 118:             Optional<ClassResolver.Info> 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) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646540627
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646541992

Reply via email to