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

这是由以下原因引起的类路径上的&nbsp;JAR，其中包含系统库中也存在的包，但java.awtJRE 系统库位于模块路径上在&nbsp;Java 平台模块系统 （JPMS）&nbsp;中，不允许在多个模块中使用相同的包。如果使用模块路径和类路径，则类路径上的所有内容都将作为模块进行处理（在您的情况下，包存在于系统模块中，并且还通过模块中类路径上的 JAR 进行处理）。<unnamed>java.awtjava.desktop<unnamed>由于&nbsp;JRE 系统库无法从模块路径移动到类路径（有关详细信息，请参阅斯蒂芬·赫尔曼的此答案），因此您只能选择以下选项：将编译器合规性设置为 1.8（如前所述）重新构建 JAR&nbsp;以避免 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&nbsp;{ &nbsp;&nbsp;&nbsp;all*.exclude&nbsp;group:&nbsp;'xml-apis'}

Answer 3

在我的情况下，这是因为我在POM.xml文件中包含了一个依赖项（阿帕奇蒂卡）。我不得不强制排除在该依赖项导入时包含错误的类的模块：&nbsp; &nbsp; <dependency>&nbsp; &nbsp; &nbsp; &nbsp; <groupId>org.apache.tika</groupId>&nbsp; &nbsp; &nbsp; &nbsp; <artifactId>tika-parsers</artifactId>&nbsp; &nbsp; &nbsp; &nbsp; <version>1.24.1</version>&nbsp; &nbsp; &nbsp; &nbsp; <exclusions>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <exclusion>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <groupId>xml-apis</groupId>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <artifactId>xml-apis</artifactId>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </exclusion>&nbsp; &nbsp; &nbsp; &nbsp; </exclusions>&nbsp; &nbsp; </dependency>它以这种方式为我工作。

Answer 4

我认为我对这个问题的了解可能是有用的。对于 下类，我得到了此错误，这些类由依赖于 、 或 等工件的旧 Maven 项目提供。javax.xml.streamxml-apisstax-apigeronimo-stax-api从技术上讲，问题在于其他人已经说过的：这些工件在没有意识到Java模块的情况下公开了包（它们是后来发明的），因此包会自动转到未命名的模块，这与JDK最新版本中包含的相同包冲突，其中这些包具有自己的模块名称（因此相同的包导致两个不同的模块， 这是被禁止的。javax.xml.*也就是说，实际的解决方案本质上是使用&nbsp;Maven 排除项，从项目中删除这些依赖项，并让它改用 JDK 版本。如果您使用的是其他构建系统，请使用等效项。从理论上讲，JDK提供的这些软件包的最新风格可能是不向后兼容的，在实践中，我怀疑这些JSR规范多年来变化很大，到目前为止，我还没有看到它们的替代品出现任何问题。