在 Java 9 中，您可以选择将源目录打包为模块，方法是添加一个 module-info.java，它定义了它导出的事物包，以及它依赖的其他模块。
但是，一旦这样做，您必须在模块描述符中列出所有依赖项 - 并且依赖项本身必须都是模块。因此，通过扩展，如果您模块化单个源目录，则必须模块化公司范围内的每个源目录。
此外，您不能在 Java 8 或更早版本中定义模块，这意味着除了模块化每个 Java 源目录之外，您还必须将所有内容都转换为 Java 9。同时。
如果您在一家拥有大量代码并由许多不同项目共享的公司工作，这似乎是灾难性的。
现在，我可以通过设置一堆编译器标志来避免定义模块来解决这个问题，但这似乎是一个非常糟糕的解决方案。
我希望我理解不正确？
但是，一旦这样做，您必须在模块描述符中列出所有依赖项
真的。
并且依赖项本身必须都是模块。
从技术上讲是正确的，但这并不意味着您认为它会做什么。
因此，通过扩展，如果您模块化单个源目录，则必须模块化公司范围内的每个源目录。
不，因为您可以让模块系统将常规的旧 JAR 转换为自动模块，这将根据清单条目或其文件名获得名称 - 您可以通过以下方式找到它：
# jar command from Java 9
jar --describe-module --file $JAR_FILE
此外，您不能在 Java 8 或更早版本中定义模块，这意味着除了模块化每个 Java 源目录之外，您还必须将所有内容都转换为 Java 9。同时。
同样，幸运的是，这并不完全正确。您可以将 a 添加module-info.class到为 Java 8 构建的 JAR 中，它适用于 Java 8（忽略该文件）和 Java 9（当然可以执行 Java 8 字节码）。
如果您模块化单个源目录，则必须模块化公司范围内的每个源目录。
不，这不成立，因为事实上，这就是自动模块的设计目的和
（倾向于冲动）是的，最终这将是模块化的目标。
重申需要从模块系统的状态引入自动模块：
自下而上的迁移很简单，但并不总是可行的。即使 的维护者
org-baz-qux.jar尚未将其转换为适当的模块——或者可能永远不会——我们可能仍然希望模块化我们的com-foo-app.jar和com-foo-bar.jar组件。
当你实际上说：
您可以选择通过添加 module-info.java 将源目录打包为模块
您倾向于将该工件迁移到模块中（带有模块描述），并进一步使用该工件将此类模块放置在库的模块路径中。
另一方面，当包含在下游项目中作为依赖项时，.jar没有 的库的a 被认为存在于类路径中。module-info.class
从评论编辑： -
可以将 Java 9 源代码与 Java 8 编译的 jar 混合，但不能编译包含 Java 9 源代码和 Java 8 源代码的单个项目？
是的，可以将 Java9 源代码与 Java8 编译 jar 混合使用，您仍然可以将它们编译到单个项目中。
示例：- 看看 Maven 如何使用包含maven-compiler-plugin的 Java8 项目执行此操作module-info.java。