在 Java 9+ 中启动 jstatd

Starting jstatd in Java 9+

过去,我通过安全策略文件启动 jstatd,如下所示:

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

我找到了一个(有问题的)解决方案:

grant {
   permission java.security.AllPermission;
};

解决方案

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

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

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

后者也感谢 Sebastian S for pointing out jdk.internal.jvmstat also needed to be granted the appropriate permission and for confirming the above works. Thanks to Gili

如下所示,tools.jar 文件已被删除,其中的所有内容都被拆分成模块。 jstatd 工具现在位于 jdk.jstatd module. I couldn't find documentation regarding how it was determined which tool(s) went into which module, though the 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. [...]

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

为了解决以上三个问题,一个新的URL方案,jrt,可以用来命名模块,classes,以及存储在[=148=中的资源]-时间图像而不揭示图像的内部结构或格式。

A jrt URL 是分层 URI,根据 RFC 3986,语法为

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

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

  • [...]

  • jrt:/$MODULE 引用模块 $MODULE.

    中的所有 class 和资源文件
  • [...]

这三种形式的jrtURL解决了上述问题如下:

  1. [...]

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

    来识别
    jrt:/jdk.crypto.ec
    

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

  3. [...]

JEP 200JEP 220 都是 Project Jigsaw.

的一部分