com.sun.xml.internal.ws.client 不存在

Question

我正在嘗試捕獲 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 Plugin 編譯，但不是從 IntelliJ Idea(via 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 也可以看到它。

有人可以解釋這種行為及其可能的解決方案嗎？

Answer 1

根據這個常見問題解答，直接調用“sun”包是一種不好的做法。 當我遇到同樣的問題時，它是通過捕獲javax.xml.ws.WebServiceException來解決的（由 artbristol 提出）。

Answer 2

您可以使用以下方法消除此錯誤：

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，需要平台版本M 的文檔化API 的簽名數據。 此數據存儲在 $JDK_ROOT/lib/ct.sym 文件中，該文件與 JDK 8 中的同名文件類似但不相同。 ct.sym 文件是一個包含精簡類的 ZIP 文件與目標平台版本中的類文件對應的文件。 對於 JDK N 和 --release N，JDK 自己的映像用作要編譯的類文件的源。 然而，可觀察模塊的列表僅限於記錄的模塊和 jdk.unsupported 模塊。

---

筆記

在這種情況下，最好不要使用ClientTransportException類，而是按照artbristol 的建議將其替換為javax.xml.ws.WebServiceException 。

Answer 3

Jre 系統庫限制了一些包對編譯器的訪問，而它們可以被 JDK 訪問。 在這種情況下，代碼中不會有錯誤，但是在編譯時會顯示諸如找不到類或找不到包之類的錯誤。

在這種情況下，有兩種做法。 1)將jre 系統庫的rt.jar添加到您的構建路徑中以進行編譯和構建。 2) 在你的構建路徑中添加jaxws-rt.jar 。

第二個選項是一個不錯的選擇，因為它可以避免在構建路徑中添加重復的庫。

Answer 4

即使在 2015 年，我也發現許多項目使用這種導入com.sun.*包的不良做法。

如果您（像我一樣）無法更改導入這些包的類，那么將rt.jar添加到您的類路徑應該可以解決問題。

請注意，所述rt.jar通常位於<jdk_home>/jre/lib文件夾下。

Answer 5

在 pom.xml 中導入此依賴項

   <dependency>
        <groupId>com.sun.xml.ws</groupId>
        <artifactId>jaxws-rt</artifactId>
        <version>2.1.4</version>
   </dependency>

Answer 6

即使我在我的 Maven 項目中也面臨同樣的問題。 我導入了import com.sun.xml.internal.ws.client.ResponseContext; 在其中一個類文件中，但這沒有被使用。 我只是在我的類文件中注釋了這一行，錯誤停止了，我可以成功運行我的 Maven 項目。

Answer 7

解決方法很簡單：當你復制現成的代碼或者先寫代碼再加載依賴時，就會出現依賴沖突。 com.sun.xml.*包已經是 JDK8 的一部分，但是 Maven 在編譯時看不到它。 因此，請確保您使用的是 mvn:repo:/...rt.jar 中的包，而不是 jdk* / .../rt.jar。

Answer 8

對於 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>

Answer 9

您不應使用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";
}