问题描述

我们使用 maven 并拥有依赖于其他内部工件的工件.我正在迁移到 java-9，并打算首先将所有内容迁移到 Java 9 而不模块化代码(即在未命名的模块中).

We use maven and have artifacts that in turn depend on other internal artifacts. I am in the process of migrating to java-9, and intend to migrate everything to Java 9 first without modularizing the code (i.e. in the unnamed module).

我遇到的问题是我们依赖于 java.xml.bind，它现在不包含在默认模块中.是否有一种正确"的方式来表达对 java.xml.bind 的这种依赖关系?

The problem I run into is that we depend on java.xml.bind, which is now not included in the default modules. Is there a "correct" way to express this dependency on java.xml.bind with Maven?

推荐答案

模块系统会说话在您从类路径加载应用程序的情况下，未命名的模块构建模块图的方式.此外，从文档本身来看:-

The Module System speaks of the way the unnamed modules as in your case of loading the application from classpath constructs the module graph. Further, from the documentation itself:-

当编译器编译未命名模块中的代码时，或者 java启动器被调用并加载应用程序的主类从类路径到应用程序类的未命名模块loader，那么未命名模块的默认根模块集是计算如下:

When the compiler compiles code in the unnamed module, or the java launcher is invoked and the main class of the application is loaded from the class path into the unnamed module of the application class loader, then the default set of root modules for the unnamed module is computed as follows:

• java.se 模块是根(如果存在).如果它不存在那么升级模块路径或系统之间的每个 java.* 模块exports 至少一个包的模块，没有限定，是根.

• The java.se module is a root, if it exists. If it does not exist then every java.* module on the upgrade module path or among the system modules that exports at least one package, without qualification, is a root.

升级模块路径或系统之间的每个non-java.*模块exports 至少一个包的模块，没有限定，是也是一个根.

Every non-java.* module on the upgrade module path or among the system modules that exports at least one package, without qualification, is also a root.

否则，默认的根模块集取决于阶段:

Otherwise, the default set of root modules depends upon the phase:

• 在编译时，它通常是正在编译的模块集(更多在下面)；

• At compile time it is usually the set of modules being compiled (more on this below);

在链接时它是空的；和

在运行时它是应用程序的主模块，通过--module(或简称 -m)启动器选项.

At run time it is the application's main module, as specified via the --module (or -m for short) launcher option.

有时需要将模块添加到默认根集中为了确保特定的平台、库或服务提供商模块将出现在模块图中.在任何阶段的选项

It is occasionally necessary to add modules to the default root set in order to ensure that specific platform, library, or service-provider modules will be present in the module graph. In any phase the option

--add-modules <module>(,<module>)* 其中 <module> 是模块名称，将命名的模块添加到默认的根模块集.

--add-modules <module>(,<module>)* where <module> is a module name, adds the named modules to the default set of root modules.

在 jetty.project 中遇到了类似的问题，其中 thread 来自 jdk 邮件列表讨论过相同的问题，修复是使用:

Similar issue was faced in jetty.project where a thread from jdk mailing list discussed over the same and the fix was to use:

--add-modules java.se.ee

这为他们提供了对所有 Java SE 模块的访问权限，在您的情况下应该是:

which provided them access to all Java SE modules and in your case shall simply be:

--add-modules java.xml.bind

要在 maven 中使用它，您可以将其嵌入到 maven-compiler-plugin使用

To use this in maven, you can embed the same to the maven-compiler-plugin using

<compilerArgs>
    <arg>--add-modules</arg>
    <arg>java.xml.bind</arg>
</compilerArgs>

按照 ZhekaKozlov 此处的建议.

as suggested by ZhekaKozlov here.

需要注意的重要一点是，将 API 标记为弃用也意味着您可能不想使用它.为了适应这种方式，您可能会开始使用对 jaxb-api:2.3.0 现在可以作为模块加载，也可以从类路径中执行.您需要进行的更改是将以下内容添加到您的依赖项列表中:

An important point to note is that marking deprecation of an API also means you might probably want to get away from using it. To adapt to this way you can probably start consuming the dependency on jaxb-api:2.3.0 which can now be loaded as a module and can be executed from the classpath as well. The change you need to make is to add the following to your dependencies list:

<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.3.0</version>
</dependency>

<小时>

更新:- 最终，Java-10 已经发布，接下来是 JDK/11，理想情况下应该点击 JEP 320:删除 Java EE 和 CORBA 模块，并用它们的**库进一步替换这些依赖项.

Update:- Eventually, with Java-10 already out and JDK/11 up next, one should ideally follow the link to JEP 320: Remove the Java EE and CORBA Modules and further replace such dependencies with their standalone libraries instead.