Java 9迁移问题-包com.mymodule在未命名的模块中声明,模块'newmodule'不读取它 [英] Java 9 migration issue - package com.mymodule is declared in unnamed module , module 'newmodule' does not read it

查看:1109
本文介绍了Java 9迁移问题-包com.mymodule在未命名的模块中声明,模块'newmodule'不读取它的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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

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

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;
}

项目编译正常,但是Intellij显示未找到模块,并且包com.mymodule在未命名的模块中声明,模块'newmodule'无法读取它.

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.

如何解决此问题?

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

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?

推荐答案

解决此问题的一种清晰方法是也将mymodule用作显式模块.我想这就是模块的理想世界.

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.

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

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

module mymodule {
    exports com.mymodule;
}


所有旧的非模块化代码默认情况下都变成 如果我什至不模块化遗留模块,那么Java 9中的自动模块?

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.

一方面,可以在模块路径上 使用模块的依赖关系本身仍然不是模块化的,而您仍然依赖于它们的模块依赖关系.视为自动模块并桥接JPMS预期的自下而上的迁移.

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.

这篇关于Java 9迁移问题-包com.mymodule在未命名的模块中声明,模块'newmodule'不读取它的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆