jnativescan-java-24-openjdk - Man Page
static analysis tool that scans one or more jar files for uses of native functionalities, such as restricted method calls or native method declarations.
Synopsis
jnativescan
[options]
- options
See Options for the jnativescan Command
Description
The jnative
tool is a static analysis tool provided by the JDK that scans a JAR file for uses of native functionalities, such as restricted method calls or native
method declarations.
jnativescan
accepts a runtime class path and module path configuration, as well as a set of root modules, and a target release. It scans the jars on the class and module paths, and reports uses of native functionalities either in a tree like structure, which also identifies that calling classes and methods, or as a list of module names when the --print-native-access
flag is specified.
Options for the Jnativescan Command
The following options are available:
- --class-path path
Used to specify a list of paths pointing to jar files to be scanned.
All jar files specified through this list will be scanned. If a jar file contains a Class-Path
attribute in its manifest, jar files listed there will be scanned as well. Jar files listed in the Class-Path
manifest attribute that can not be found are ignored. All the jar files found are treated as if they belonged to the unnamed module.
- --module-path path
Used to specify a list of paths pointing to jar files or directories containing jar files, that the tool can use to find modules that need to be scanned. The list of jar files that will be scanned depends on the
--add-modules
option.For both the
--class-path
and--module-path
options, path should be a search path that consists of one or more jar files, separated by the system-specific path separator. For example:Linux and macOS:
--class-path /some/foo.jar:/another/different/bar.jar
Note:
On Windows, use a semicolon (
;
) as the separator instead of a colon (:
).Windows:
--class-path C:\some\foo.jar;C:\another\different\bar.jar
- --add-modules module[,module...]
Used to specify a comma-separated list of module names that indicate the root modules to scan. All the root modules will be scanned, as well as any modules that they depend on. This includes dependencies on service implementations specified through the
uses
directive in a module'smodule-info
file. All modules found on the module path that provide an implementation of such a service will be scanned as well.- --release version
Used to specify the Java SE release that specifies the set of restricted methods to scan for. For multi-release jar files, this option also indicates the version of class file that should be loaded from the jar. This option should be set to the version of the runtime under which the application is eventually intended to be run. If this flag is omitted, the version of
jnativescan
is used as release version, which is the same as the version of the JDK that the tool belongs to.- --print-native-access
Print a comma-separated list of module names that use native functionalities, instead of the default tree structure.
- --help or -h
Prints out a full help message.
- --version
Prints out the abbreviated version string of the tool.
EXAMPLE OF jnativescan USE
jnativescan
accepts a runtime configuration in the form of a class path, module path, set of root modules, and a target release version. For the class path, the tool will scan all jar files, including those found recursively through the Class-Path
manifest attribute. For the module path, the tool scans all root modules specified through --add-modules
, and any (transitive) dependence of the root modules, including any modules that contain service implementations that are used by a scanned module.
By default, the tool prints out which jars, classes, and methods use native functionalities, in a tree-like structure. The following is an example output:
$ jnativescan --class-path app.jar app.jar (ALL-UNNAMED): foo.Main: foo.Main::main(String[])void references restricted methods: java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment foo.Main::nativeMethod()void is a native method declaration
app.jar (ALL-UNNAMED)
is the path to the jar file, with the module name in parentheses behind it. Since in this case the jar file appears on the class path, ALL-UNNAMED
is printed to indicate the unnamed module. The second line of the output, foo.Main
, indicates that methods using native functionalities were found in the foo.Main
class. The next line:
foo.Main::main(String[])void references restricted methods:
Indicates that the main(String[])
method in the foo.Main
class references a restricted method, which is listed on the following line as:
java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
Lastly, the text:
foo.Main::nativeMethod()void is a native method declaration
Indicates that the foo.Main
class contains a declaration of a native
method named nativeMethod
.
If we add --print-native-access
to the example command line, we instead get a list of the names of modules that contain accesses to native functionalities:
$ jnativescan --class-path app.jar --print-native-access ALL-UNNAMED
In this case the output consists of just ALL-UNNAMED
, which indicates a jar file on the class path, that is, in the unnamed module, contains an access to native functionalities.