Java模块解析语境下'at the discretion of the host system'的含义是什么

问题解答 #

1. 宿主系统是否可以直接判定foo不参与已解析的模块图？ #

答案是否定的。
此处官方文档里的at the discretion of the host system翻译为「由宿主系统自行决定」，实际含义是：宿主系统有权自主选择是否将无transitive修饰符的requires指令指向的模块纳入递归枚举范围，而非必须将其排除。
也就是说在你的模块仅声明requires foo;的前提下：

• 遵循JPMS默认解析规则时，非transitive的间接依赖不会被自动拉入模块图，但只要foo真实存在，宿主系统完全可以根据自身场景需求主动将foo加入解析范围，该操作完全符合规范要求。

2. 官方特意明确该规则的原因 #

Java模块系统（JPMS）的设计同时兼顾了默认规则的严谨性和多场景的灵活性，预留该自主决策权限主要为了覆盖以下几类合法场景：

递归枚举接收一组模块名，查询每个模块的声明信息，针对每个模块声明，递归枚举如下内容：

• 带transitive修饰符的requires指令指定的模块名；
• 由宿主系统自行决定，无transitive修饰符的requires指令指定的模块名。

• 适配上层容器的自定义规则：应用服务器、微服务运行框架、类OSGi的模块化系统这类上层宿主，往往有自定义的部署逻辑、类加载规则，该规则允许它们根据自身需求调整依赖枚举范围，不需要被JPMS的默认递归逻辑限制。
• 满足JDK工具链的特殊需求：jlink（构建自定义运行时镜像）、jdeps（依赖分析）、jmod（模块处理）这类JDK内置工具，在执行服务绑定（比如jlink的--bind-services参数会主动拉取服务提供者的所有依赖，包含非transitive类型）、全依赖扫描、问题诊断等场景时，需要枚举所有requires指向的模块，该规则为这类工具的实现提供了规范依据。
• 兼容运行时的自定义配置：普通Java进程启动时，用户可以通过--add-modules等启动参数主动添加非transitive的间接依赖，这类操作也属于宿主系统（此处为JDK启动器）的自主决策范围，符合规范定义。

内容的提问来源于stack exchange，提问作者Laird Nelson