What does “Required filename-based automodules detected.” warning mean?

后端 未结 4 1940
鱼传尺愫
鱼传尺愫 2020-12-08 21:15

In my multi-module project, I created module-info.java only for few modules. And during compilation with maven-compiler-plugin:3.7.0 I\'m getting n

4条回答
  •  南方客
    南方客 (楼主)
    2020-12-08 21:36

    Automatic module recap

    An explicit module (i.e. one with a module-info.java) can only access code of modules that it requires (ignoring implied readability for a moment). That's great if all dependencies are modularized, but what if they are not? How to refer to a JAR that isn't modular?

    Automatic modules are the answer: Any JAR that ends up on the module path gets turned into a module. If a JAR contains no module declaration, the module system creates an automatic module with the following properties:

    • inferred name (this is the important bit here)
    • reads all other modules
    • exports all packages

    Maven relies on that mechanism and once you create a module-info.jar it places all dependencies on the module path.

    Automatic names

    There are two ways to infer an automatic module's name:

    • entry in the manifest
    • guess from the JAR file name

    In the first case, the name was deliberately picked by the maintainer, so it can be assumed to be stable (for example it doesn't change when the project gets modularized). The second one is obviously unstable across the ecosystem - not all project setups lead to the exact same file names of their dependencies.

    What does it mean?

    The reason for the warnings are that some of your dependencies are automatic modules and do not define their future module name in the manifest. Instead, their name is derived from the file name, which makes them unstable

    Stable names

    So why are unstable names such a problem? Assume your library gets published with requires guava and my framework gets published with requires com.google.guava. Now somebody uses your library with my framework and suddenly they need the modules guava and com.google.guava on their module path. There is no painless solution to that problem, so it needs to be prevented!

    How? For example by discouraging developers from publishing artifacts that depend on filename-based automatic modules.

提交回复
热议问题