Eclipse 被导入所混淆（“可从多个模块访问”）

Question

引用简单的.jar文件时，Eclipse 会显示一个错误，指出：可以从多个模块访问 java.awt 包：<未命名>，java.桌面例如，当 或 包含在.jar文件中时，就会发生这种情况。javax.awtjavax.swing最简单的示例如下：package test;import javax.swing.JDialog;public class Test {    public static void main(String[] args) {        new JDialog();    }}将.jar文件添加到仅具有文件夹结构（不需要文件）的类路径将导致出现错误。我使用的是JDK 10/12（两者都不起作用）。设置编译器合规性以使整个事情再次工作。在另一台计算机上，此工作与编译器合规性设置为 。javax/swing1.8Eclipse 2018-0910我在Eclipse上，在一个（出于测试目的）新安装的，它工作正常。为什么？2019-03Eclipse 2018-09编辑2020年6月（解决方案）正如答案正确指出的那样，这是很久以前在Java中内置的限制，直到最近才强加给我们。我在将一个具有数十个依赖项的大项目迁移到Maven时接触到了它。有2000年左右的图书馆！有“元库”，它由几个打包在一起的库组成。因此，除了确定仍然需要什么（与其他库一起进入垃圾箱！），更新违反规则的库或找到它们的替代品之外，没有其他方法。这花了我很多很多个小时。最后，它成功了，我们有一个不错的Maven项目可以合作。

Answer 1

这是由以下原因引起的

• 类路径上的 JAR，其中包含系统库中也存在的包，但java.awt

• JRE 系统库位于模块路径上

在 Java 平台模块系统 （JPMS） 中，不允许在多个模块中使用相同的包。如果使用模块路径和类路径，则类路径上的所有内容都将作为模块进行处理（在您的情况下，包存在于系统模块中，并且还通过模块中类路径上的 JAR 进行处理）。<unnamed>java.awtjava.desktop<unnamed>

由于 JRE 系统库无法从模块路径移动到类路径（有关详细信息，请参阅斯蒂芬·赫尔曼的此答案），因此您只能选择以下选项：

• 将编译器合规性设置为 1.8（如前所述）

• 重新构建 JAR 以避免 JAR 中的 Java 系统库包名称（如果使用反射，则可能需要进行其他代码更改）：

• 如果您有源代码，请更改软件包名称（例如，将软件包和子软件包更改为 和 ）并重新创建 JARjavajava_utiljavaxjavax_util

• 如果您只有文件，则必须先反编译文件.class.class

Answer 2

由于我敢打赌很多人会在模块化Java中遇到这个问题，所以我会提供帮助并给出真正的答案。

此错误发生在以下情况下

• 您的项目中有依赖项

• 包含代码

• 使用包

• 也在模块中

• 被您的项目引用

如果您的项目已将源代码兼容性设置为类似于 Java 12 的内容，它将开始强制执行该规则，该规则在 Java 中一直存在：

“不要在自己的代码中使用属于 JDK 的包。

不幸的是，多年来，许多开发人员和供应商都这样做了。不能再那样做了。

如果您将项目设置为 Java 12 源代码兼容性，Eclipse 会添加 JDK 模块，其中包括所有“java.*”和“javax.*”，甚至“jdk.*”、“org.w3c.*”。这些包可能正由依赖项或其传递依赖项使用。

如何修复

您需要：

• 看看它抱怨的是哪个包裹

• 并展开包资源管理器中的“项目和外部依赖项”节点。

• 找出哪个依赖项正在使用该包。

• 然后，您只需从项目中排除该依赖项即可。

或者，您可以获取该依赖项的源代码（如果可用），并使用更改的包重新生成 jar。否则，您必须删除该依赖关系并找到该技术的替代品。疼吧？

如果它是一个可传递的依赖项，您通常可以将其排除。以下是基于 Gradle 的项目的示例。

GradleConfig.xml：

configurations {
   all*.exclude group: 'xml-apis'}

Answer 3

在我的情况下，这是因为我在POM.xml文件中包含了一个依赖项（阿帕奇蒂卡）。

我不得不强制排除在该依赖项导入时包含错误的类的模块：

    <dependency>

        <groupId>org.apache.tika</groupId>

        <artifactId>tika-parsers</artifactId>

        <version>1.24.1</version>

        <exclusions>

            <exclusion>

                <groupId>xml-apis</groupId>

                <artifactId>xml-apis</artifactId>

            </exclusion>

        </exclusions>

    </dependency>

它以这种方式为我工作。

Answer 4

我认为我对这个问题的了解可能是有用的。

对于 下类，我得到了此错误，这些类由依赖于 、 或 等工件的旧 Maven 项目提供。javax.xml.streamxml-apisstax-apigeronimo-stax-api

从技术上讲，问题在于其他人已经说过的：这些工件在没有意识到Java模块的情况下公开了包（它们是后来发明的），因此包会自动转到未命名的模块，这与JDK最新版本中包含的相同包冲突，其中这些包具有自己的模块名称（因此相同的包导致两个不同的模块， 这是被禁止的。javax.xml.*

也就是说，实际的解决方案本质上是使用 Maven 排除项，从项目中删除这些依赖项，并让它改用 JDK 版本。如果您使用的是其他构建系统，请使用等效项。

从理论上讲，JDK提供的这些软件包的最新风格可能是不向后兼容的，在实践中，我怀疑这些JSR规范多年来变化很大，到目前为止，我还没有看到它们的替代品出现任何问题。