24

我正在尝试捕获 ClientTransportException 并且我的程序在编译阶段失败，并出现以下异常

[ERROR]\workspace\rates\java\service\bundle1\src\main\java\com\connector\ws\TestClass1.java:[72,70] package com.sun.xml.internal.ws.client does not exist

据我所知，这个包来自 rt.jar 并且存在于 jre

如果我添加 @SuppressWarnings("restriction") 它从 Eclipse Maven 插件编译，但不是从 IntelliJ Idea（通过 maven）或命令行编译。

当我删除 @SuppressWarnings Eclipse 时显示以下警告

Access restriction: The type ClientTransportException is not accessible due to restriction on required library C:\Program Files\Java\jre6\lib\rt.jar

我发现了类似的问题，但它的答案对我来说还不够清楚，因为我可以在 rt.jar 中看到这个类，而我的 IntelliJ Idea 也可以看到它。

有人可以解释这种行为和可能的解决方案吗？

4

9 回答 9

22

根据这个常见问题解答，直接调用“sun”包是一种不好的做法。当我遇到同样的问题时，它通过捕获javax.xml.ws.WebServiceException来解决（如 artbrisol 所建议的）。

于 2013-08-19T17:28:40.313 回答
16

您可以使用以下方法消除此错误：

javac -XDignore.symbol.file=true

这是传递给 javac 以使用 rt.jar 而不是 ct.sym 的参数（默认使用ct.sym并且需要编译到目标旧版本）

ct.sym不包含 rt.jar 中的所有类。因为sun.*不应该使用使用类，所以它们的类存根可能不会出现在ct.sym编译失败中。

删除调用sun.*应该可以解决这个问题。（使用 sun 包是一种不好的做法）

参考 ：

https://blogs.oracle.com/geertjan/ctsym-steals-the-asm-class

事情的真相是在 JDK 中有一个叫做“ct.sym”的东西。当 javac 编译代码时，它不会链接到 rt.jar。相反，它使用带有类存根的特殊符号文件 lib/ct.sym。内部 JDK 类没有放在该符号文件中，因为它们是内部类。你根本不想使用它们。

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6778491

这不是编译器问题。根据 ct.sym 中提供的信息，javac 行为正确。这个问题属于那些决定什么应该可用（以及什么应该被隐藏）ct.sym 我还不能确定这个错误的正确类别。这是故意的。也许包名称“com.sun.xml.internal ....”可能被视为一个提示。用户不应编写依赖于内部 JDK 实现类的代码。这些类是 JDK 的内部实现细节，如有更改，恕不另行通知。

http://openjdk.java.net/jeps/247

对于JDK N和--release M，M < N，需要平台的release M的文档化API的签名数据。此数据存储在 $JDK_ROOT/lib/ct.sym 文件中，该文件与 JDK 8 中的同名文件相似但不相同。ct.sym 文件是一个包含精简类的 ZIP 文件与目标平台版本中的类文件对应的文件。对于 JDK N 和 --release N，JDK 自己的映像用作要编译的类文件的源。然而，可观察模块列表仅限于文档化模块和 jdk.unsupported 模块。

笔记

在这种情况下，最好不要使用ClientTransportException该类并将其替换为javax.xml.ws.WebServiceException，如artbristol所建议的那样。

于 2012-05-16T09:27:07.203 回答
4

Jre 系统库限制了一些包对编译器的访问，而它们可以被 JDK 访问。在这种情况下，代码不会出现错误，但是在编译时会显示诸如找不到类或找不到包之类的错误。

在这种情况下，有两种做法。 1）将jre系统库的rt.jar添加到你的构建路径中进行编译构建。2)在构建路径中添加jaxws-rt.jar 。

第二个选项是一个不错的选择，因为它可以避免将重复的库添加到您的构建路径中。

于 2016-04-27T11:07:58.777 回答
3

即使在 2015 年，我也发现许多项目使用了这种导入com.sun.*包的不良做法。

如果您（像我一样）无法更改导入这些包的类，那么添加rt.jar到您的类路径应该可以解决问题。

请注意，所说rt.jar的通常位于<jdk_home>/jre/lib文件夹下。

于 2015-08-10T14:12:56.043 回答
3

在 pom.xml 中导入此依赖项

   <dependency>
        <groupId>com.sun.xml.ws</groupId>
        <artifactId>jaxws-rt</artifactId>
        <version>2.1.4</version>
   </dependency>
于 2018-05-23T15:57:55.727 回答
2

解决方法很简单：复制现成的代码或者先写代码再加载依赖，就会出现依赖冲突。com.sun.xml.*package 已经是 JDK8 的一部分，但是 Maven 在编译时看不到它。因此，请确保您使用 mvn:repo:/...rt.jar 中的包，而不是 jdk* / .../rt.jar。在此处输入图像描述

于 2020-05-14T18:00:32.670 回答
2

即使我在我的 Maven 项目中也面临同样的问题。我已经导入 import com.sun.xml.internal.ws.client.ResponseContext;了一个类文件，但这没有被使用。我刚刚在我的类文件中注释了这一行，错误停止了，我可以成功运行我的 maven 项目。

于 2017-04-06T13:59:17.077 回答
0

对于 Maven 构建，添加以下插件将解决该问题。

基本上添加编译器参数以引用 tools.jar 的正确路径

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
            <source>1.8</source>
            <target>1.8</target>
            <compilerArguments>
                <bootclasspath>${java.home}/lib/rt.jar${path.separator}${java.home}/lib/jce.jar${path.separator}${java.home}/../lib/tools.jar</bootclasspath>
            </compilerArguments>
        </configuration>
    </plugin>
于 2021-05-25T03:19:03.737 回答
-1

你不应该使用com.sun.*包。我们可以通过使用我们自己的类来解决这个问题：

/**
 * Copy of com.sun.xml.internal.ws.client.BindingProviderProperties since we're
 * not allowed to use com.sun.* packages..     
 */
public final class BindingProviderProperties {
    public static final java.lang.String CONNECT_TIMEOUT = "com.sun.xml.internal.ws.connect.timeout";
    public static final java.lang.String REQUEST_TIMEOUT = "com.sun.xml.internal.ws.request.timeout";
}
于 2017-12-06T14:27:55.700 回答