Java 9 migration issue – package com.mymodule is declared in unnamed module , module ‘newmodule’ does not read it

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?

Answer

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.