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.symdoes 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.