com.sun.xml.internal.ws.client does not exist

Question

I'm trying to catch ClientTransportException and my program fails on compilation stage with the following exception

[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

As I know this package is from rt.jar and exist in jre

If I add @SuppressWarnings("restriction") it compiles from Eclipse Maven Plugin, but not from IntelliJ Idea(via maven) or command line neither.

When I remove @SuppressWarnings Eclipse show the following warning

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

I've found similar question but it's answer isn't clear enough for me cause I can this class in rt.jar and my IntelliJ Idea can see it either.

Can someone explain such behavior and possible solution for it?

Answer 1

According to this FAQ it's a bad practice to directly call 'sun' packages. When I ran into the same problem it was fixed by catching javax.xml.ws.WebServiceException instead (as sugested by artbristol).

Answer 2

You can get rid of this error using :

javac -XDignore.symbol.file=true

That's the argument to pass to javac to use rt.jar instead of ct.sym ( ct.sym is used by default and required for compiling to a target older version)

ct.sym does not contains all classes from rt.jar. Because using sun.* classes should not be used the class stub for them might not be present in in ct.sym making the compilation fails.

Removing calls to sun.* should remove this issue. (It's a bad practice to use sun packages)

References :

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

The truth of the matter is that there's something called "ct.sym" in the JDK. When javac is compiling code, it doesn't link against rt.jar. Instead, it uses a special symbol file lib/ct.sym with class stubs. Internal JDK classes are not put in that symbol file, since those are internal classes. You shouldn't want to use them, at all.

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

This is not a compiler issue. javac is behaving correctly, according to the information provided in ct.sym. The issue belongs with those who decide what should be available with (and what should be hidden by) ct.sym I cannot as yet determine the correct category for this bug. This is intentional. Perhaps the package name "com.sun.xml.internal...." might be seen as a hint. Users should not write code that depends on internal JDK implementation classes. Such classes are internal implementation details of the JDK and subject to change without notice.

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

For JDK N and --release M, M < N, signature data of the documented APIs of release M of the platform is needed. This data is stored in the $JDK_ROOT/lib/ct.sym file, which is similar, but not the same, as the file of the same name in JDK 8. The ct.sym file is a ZIP file containing stripped-down class files corresponding to class files from the target platform versions. For JDK N and --release N,the JDK's own image is used as the source of the class files to compile against. The list of observable modules is limited, however, to the documented modules and the jdk.unsupported module.

---

NOTE

In this case, it would be better to not use the ClientTransportException class and replaced it by javax.xml.ws.WebServiceException , as suggested by artbristol .

Answer 3

Jre System library restricts some packages access to compiler, while they are accessible to JDK. In that case there will be no error in code but when compiling it will show errors like class not found or package not found.

In that case there are two practices. 1) Add rt.jar of jre system library to your build path for compiling and building. 2) Add jaxws-rt.jar in your build path.

Second option is a good option as it will avoid adding duplicate libraries to your build path.

Answer 4

Even in 2015, I've found many projects that use this bad practice of importing com.sun.* packages.

If you (like me) can't change the classes importing those packages, adding rt.jar to your classpath should do the trick.

Note that the said rt.jar is usually found under <jdk_home>/jre/lib folder.

Answer 5

import this dependency in pom.xml

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

Answer 6

Even I was facing same issue in my maven project. I had imported import com.sun.xml.internal.ws.client.ResponseContext; in one of class file but this was not in use. I just commented the line in my class file and the error stopped and i could successful run my maven project.

Answer 7

The solution is quite simple: when you copy the ready-made code or write the code first and then load the dependencies, there is a dependency conflicts. com.sun.xml.* package is already part of JDK8, but Maven does not see it when compiling. So make sure that you use the package from mvn:repo:/...rt.jar not jdk* / .../rt.jar.

Answer 8

For maven build adding the following plugin will resolve the issue.

Basically adding the compiler arguments to refer correct path of 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

You should not use com.sun.* packages. We could solve the problem by using our own class instead:

/**
 * 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";
}