2

我猜自动模块：

http://openjdk.java.net/projects/jigsaw/spec/sotms/#automatic-modules

意味着需要第 3 方 jar 的项目的每个模块都必须将该 jar 打包到它自己的模块化 jar中。如果是这样的话，一个大型的多模块应用程序最终会不会比它的基于类路径的 Java 8 应用程序更大？我正在考虑所有几乎无处不在的 apache 库和其他常见的开源依赖项。

我在未来获得胜利；所有这些 3rd 方库本身都是模块化的，因此只需要分发最小的配置。但是，在短期内，如果没有类路径，那里不会有一些非常庞大的模块化 jar 吗？还是我错过了什么？

4

2 回答 2

4

我认为您误解了自动模块的工作原理。它们的关键属性是您可以使用现有的非模块化 JAR，将它们放在模块路径上，并让它们作为模块出现，以便编译或运行时。

我猜自动模块意味着需要第 3 方 jar 的项目的每个模块都必须将该 jar 打包到它自己的模块化 jar 中。

一点都不。恰恰相反，您重用了现有的 JAR。

于 2017-06-18T10:39:08.883 回答
1

您的问题和评论暗示类路径正在消失：它不是。

在讨论自动模块之前，还有其他概念需要了解。

在 Java 9 中，类路径仍然存在，熟悉的遗留 jars（即非模块化 jars）仍然可以工作。但是，还有一个包含模块化 jar 的新模块路径。

模块化 jar 包含一个module-info.class非常明确的（a）作为依赖项所需的模块和（b）导出哪些包。

一个关键点是类路径和模块路径之间的交互：

  • 类路径上的旧版 jar 对模块路径一无所知，因此它们被授予对所有模块的访问权限。
  • 因为类路径通常是混乱的，所以它被称为未命名模块。因为没有名称，模块路径上的模块化 jar 不能在其module-info.java.

有了这么多信息，就不可能以零碎的方式模块化项目：如果应用程序 jar 需要第 3 方库，我们将不得不 (a) 等待库作者对其进行模块化或 (b) 尝试自己模块化。两者都是非首发。

输入自动模块。它们是位于模块路径上的遗留（非模块化）jar。它们充当类路径和模块路径之间的桥梁，因为：

  • 自动模块被命名（机制可能是一个单独的问题），并且可以被模块引用。
  • 自动模块被授予对未命名模块中的所有内容（即类路径上的遗留 jar）和模块路径上的所有模块（即 JDK 模块）的读取访问权限。

此视频和此视频提供插图。

于 2017-06-23T09:42:14.990 回答