Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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?
                Thanks, I'm reading it right now, but I see only one implementation of ClientTransportException in my project.
– Alexander Zhugastrov
                May 16, 2012 at 8:52
                Thanks, @Jesper, I have already read this article in this question but it tells that I shouldn't use it but still I can. Unfortunately I need to catch this exception it caused by legacy of our progect
– Alexander Zhugastrov
                May 16, 2012 at 9:03
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.
                @Thomas Yes, unfortunately I remember the article was quite long so I didn't quote it in the answer. Currently I can't find a new website where Andrew Haley reposted it...
– alain.janinm
                Oct 17, 2013 at 12:14
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.
                How to do that? could you explain this? I got a similar error here is : "package com.sun.xml.internal.ws.developer does not exist" only "clien" and "developer". Could you explain your solution and how to I do that?
– luffy
                Jun 30, 2016 at 13:05
                Go to properties of your project, where you add system libraries. you would have an option to add jre system library. add it to your build path. error should be resolved.
– Fakhar uddin Malik
                Jul 26, 2021 at 13:02
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.
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.
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.
                Ahah, quite the same for me... In my case I mistakenly added import com.sun.xml.internal.ws.policy.AssertionValidationProcessor with the auto completion but I wanted org.junit.Assert...
– potame
                Jul 6, 2020 at 14:25
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>
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";
                How will this help if those properties are not even used internally? What's the point of setting them?
– lovrodoe
                May 13, 2021 at 7:12
                You says that we should not use com.sun.xml. But you use it as package name, so you use it.
– Mikhail Ionkin
                Dec 2, 2021 at 8:32
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.