Java 9 迁移问题 - 包 com.mymodule 在未命名的模块中声明，模块“newmodule"不读取它

我创建了一个具有以下结构的多模块项目

 我的项目|- 我的模块|- 源|- 主要|- 爪哇|- com|- 我的模块|- 实用程序.java|-新模块|-src|-主要|-java|-com|-新模块|- 主.java|-模块信息.java

现在我想使用 Util.java，它是模块化模块 newmodule 中的非模块化代码.我已经在 newmodule 中声明了以下内容

模块新模块{需要我的模块；}

项目编译正常，但 Intellij 显示未找到模块，并且包 com.mymodule 在未命名模块中声明，模块newmodule"不读取它.

如何解决这个问题?

还有一个问题，如果我什至不模块化遗留模块，所有旧的非模块化代码在默认情况下会在 java 9 中变成自动模块吗?

解决方案

解决此问题的一个明确方法是将 mymodule 也设为显式模块.这就是我想说的理想的模块世界.

您也可以通过在 mymodule 中包含一个 module-info.java 来做到这一点，例如 -

模块 mymodule {出口 com.mymodule;}

<小时><块引用>

所有旧的非模块化代码是否默认变成如果我什至不模块化遗留模块，java 9 中的自动模块?

未命名模块和自动模块的概念都是为了帮助迁移并提供与现有类路径技术的兼容性.

一方面，您的模块的依赖项本身仍然不是模块化的，您仍然依赖它们是一个，可以在模块路径上使用隐式定义它们的模块系统，当被视为 自动模块 并架起 JPMS 预期的自下而上迁移的桥梁.

未命名的模块另一方面依赖于没有在任何模块中定义的类型，并且被解析为仍然可以在类路径中找到.这确保了解析的每个类型都是某个模块的一部分(如果没有，则为未命名的模块)，并且还提供了兼容性，使得依赖类路径的现有应用程序的代码也可以在模块系统上类似地编译和运行.

<小时>

文档中明确说明了您无法在代码中声明显式依赖的原因:-

<块引用>

未命名的模块导出其所有包.这使得灵活迁移，我们将在下面看到.但是，这并不意味着代码在命名模块中可以访问未命名模块中的类型.一个有名字的实际上，模块甚至不能声明对未命名的依赖module. 这个限制是有意的，因为允许命名模块依赖于类路径的任意内容会使可靠的配置是不可能的.

I have created a multimodule project with the following structure

    myproject
      |- mymodule
         |- src
            |- main
               |- java
                  |- com
                     |- mymodule
                        |- Util.java

      |-newmodule
         |-src
           |-main
             |-java
               |-com
                 |-newmodule
                    |- Main.java
             |-module-info.java

Now i want to use Util.java which is a non modularized code in a modularized module newmodule. i have declared following in newmodule

module newmodule {
    requires mymodule;
}

Project is compiling fine, but Intellij is showing module not found and package com.mymodule is declared in unnamed module , module 'newmodule' does not read it.

How to resolve this issue?

And one more question does all the old non modular code is by default turn into automatic-module in java 9 if i don't even modularized legacy modules?

解决方案

One clear way to resolve this is to make the mymodule as an explicit module as well. This would just be the ideal world of modules I would say.

You can do that by including a module-info.java in mymodule as well, something like -

module mymodule {
    exports com.mymodule;
}

---

does all the old non modular code is by default turn into automatic-module in java 9 if i don't even modularized legacy modules?

The concept of both the unnamed module and automatic module is to aid the migration and provide the compatibility with the existing classpath techniques.

On one hand, the dependencies of your module which are still not themselves modular and you would still rely on them being one, can be used on the module path for the module system to implicitly define them, when treated as automatic modules and bridge the bottom-up migration expected by JPMS.

The unnamed modules on the other hand relies on the type that is not defined in any module and is resolved to be still found on the classpath. This ensures that every type resolved is part of some module(if nothing then the unnamed module) and also provides the compatibility such that code of existing applications relying on the classpath shall compile and run similarly on module system as well.

---

The reason, why you would fail to declare an explicit dependence in your code is stated clearly in the doc:-

The unnamed module exports all of its packages. This enables flexible migration, as we shall see below. It does not, however, mean that code in a named module can access types in the unnamed module. A named module cannot, in fact, even declare a dependence upon the unnamed module. This restriction is intentional, since allowing named modules to depend upon the arbitrary content of the class path would make reliable configuration impossible.