过去，我通过安全策略文件启动 jstatd，如下所示: https://stackoverflow.com/a/14930180/1294116

但是，在 Java 9+ 中，他们删除了 tools.jar 文件，这意味着该解决方案不再有效。有谁知道如何解决这个问题？ (目前我又收到错误 java.security.AccessControlException: access denied ("java.util.PropertyPermission""java.rmi.server.ignoreSubClasses""write") ...)

最佳答案

解决方案

以下策略文件应该适合您(至少在 Java 11 下):

grant codebase "jrt:/jdk.jstatd" {    
   permission java.security.AllPermission;    
};

grant codebase "jrt:/jdk.internal.jvmstat" {    
   permission java.security.AllPermission;    
};

感谢Sebastian S指出 jdk.internal.jvmstat 也需要被授予适当的权限并确认上述工作。感谢Gili对于后者也是如此。

如下所示，tools.jar 文件已被删除，其中的所有内容都被拆分成模块。 jstatd 工具现在驻留在 jdk.jstatd 中模块。我找不到关于如何确定哪个工具进入哪个模块的文档，虽然 Javadoc事后告诉你。请注意，一些模块包含单个工具的代码，而其他模块包含多个工具的代码。

文档

来自Policy File Syntax文档:

If you are using a modular runtime image (see the jlink tool), you can grant permissions to the application and library modules in the image by specifying a jrt URL as the codeBase value in a policy file. See JEP 220: Modular Run-Time Images for more information about jrt URLs.

The following example grants permission to read the foo property to the module com.greetings:

grant codeBase "jrt:/com.greetings" {
   permission java.util.PropertyPermission "foo", "read";
};

来自 JEP 200: The Modular JDK :

Design principles

The modular structure of the JDK implements the following principles:

• Standard modules, whose specifications are governed by the JCP, have names starting with the string "java.".
• All other modules are merely part of the JDK, and have names starting with the string "jdk.".

[...]

来自 JEP 220: Modular Run-Time Images :

Summary

Restructure the JDK and JRE run-time images to accommodate modules and to improve performance, security, and maintainability. Define a new URI scheme for naming the modules, classes, and resources stored in a run-time image without revealing the internal structure or format of the image. Revise existing specifications as required to accommodate these changes.

[...]

Removed: rt.jar and tools.jar

The class and resource files previously stored in lib/rt.jar, lib/tools.jar, lib/dt.jar, and various other internal JAR files are now stored in a more efficient format in implementation-specific files in the lib directory. The format of these files is not specified and is subject to change without notice.

The removal of rt.jar and similar files leads to three distinct problems:

1. [...]

2. The java.security.CodeSource API and security-policy files use URLs to name the locations of code bases that are to be granted specified permissions. Components of the run-time system that require specific permissions are currently identified in the lib/security/java.policy file via file URLs. The elliptic-curve cryptography provider, e.g., is identified as

   file:${java.home}/lib/ext/sunec.jar
   

   显然，这在模块化图像中没有任何意义。

3. [...]

用于命名存储模块、类和资源的新 URI 方案

为了解决上述三个问题，可以使用新的 URL 方案 jrt 来命名存储在运行时镜像中的模块、类和资源，而不会泄露内部结构或格式图片。

jrt URL 是一个层次化的 URI，符合 RFC 3986 的语法

jrt:/[$MODULE[/$PATH]]

其中 $MODULE 是可选的模块名称，$PATH(如果存在)是该模块中特定类或资源文件的路径。 jrt URL 的含义取决于它的结构:

• [...]

• jrt:/$MODULE 引用模块$MODULE中的所有类和资源文件。

• [...]

这三种形式的jrt URL解决了上述问题，如下所示:

1. [...]

2. 安全策略文件和 CodeSource API 的其他用途可以使用 jrt URL 来命名特定模块以授予权限。椭圆曲线加密提供者，例如，现在可以通过 jrt URL

   来识别

   jrt:/jdk.crypto.ec
   

   其他当前被授予所有权限但实际上并不需要它们的模块可以轻松地被取消特权，即，精确地给予它们所需的权限。

3. [...]

JEP 200 和 JEP 220 都是 Project Jigsaw 的一部分.

关于java - 在 Java 9+ 中启动 jstatd，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51032095/